Tue 06 Aug 2013 03:50:53 PM UTC, comment #10:
It's not good. I started a build of a current mercurial snapshot with the intent of looking into bug #35588. The build failed in oct-time.cc with an error in gnulib's sys/time.h. That's as far as I've gotten, I'll try to get past that and on to the next error when I have time to work on it.
|
Sun 23 Jun 2013 10:21:58 PM UTC, comment #9:
Can someone verify how the development branch of Octave from Mercurial builds on OpenBSD? The build process has really been re-worked and we use Autconf and gnulib quite a lot to try and get better cross-platform building.
|
Tue 21 Feb 2012 07:52:38 PM UTC, comment #8:
I can conform that this breakage is still upon us:
|
Mon 20 Feb 2012 08:46:48 PM UTC, comment #7:
Could the original report re-verify whether this is still a problem with a new 3.6.1 release candidate (ftp://alpha.gnu.org/gnu/octave/)? If it is, the problem needs to be reported to the gnulib bug tracker since it is not strictly an issue with Octave code. Since the goal of gnulib is to have cross-platform portability I think they would be fairly motivated to figure out why base functions are failing on a well-known OS like OpenBSD.
|
Fri 04 Nov 2011 08:46:36 PM UTC, comment #6:
OK, so if I remove all of the gnulib:: namespacing from sighandlers.cc octave actually runs!
So the gnulib signal handler funcs do not work on OpenBSD.
Patch I used attached - not sure how you plan to work around this upstream.
(file #24303)
|
Fri 04 Nov 2011 01:27:22 PM UTC, comment #5:
Hi John,
Having worked around #34725, we should figure out what is wrong here. I had previously applied a patch which worked around a build error. I am attaching it.
With this patch applied, I get the following seg:
What is supposed to happen here, am I supposed to be using gnulib replacements? OpenBSD has implementations of both sigaddset and sigemptyset.
It looks here like I am mixing implementations, so in a way it does not surprise me that this does not work.
Can you comment? Did the build system do the right thing in choosing gnulib? If so, the original assembler message is our blocker, otherwise, the build system erroneously chose to replace system functions.
Can you comment?
(file #24301)
|
Mon 31 Oct 2011 01:01:52 PM UTC, comment #4:
Any idea?
|
Fri 28 Oct 2011 09:29:36 AM UTC, comment #3:
For what it is worth, I have the same failure with gcc/g++-4.2.4
|
Thu 27 Oct 2011 11:04:46 PM UTC, comment #2:
Standard OpenBSD GCC:
% gcc --version
gcc (GCC) 4.2.1 20070719
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
Thu 27 Oct 2011 01:31:37 AM UTC, comment #1:
I have no clue what could cause an assembler failure like that. What version of GCC are you using?
|
Wed 26 Oct 2011 11:16:08 PM UTC, original submission:
Hi,
Using the 3.4.3 release tarball, the build fails like this on OpenBSD-current/amd64:
Whilst I can kludge this to use the non-gnulib implementation (which is included in OpenBSD and is not a macro), I feel that this is not the right thing to do.
I am attaching a config.log and a build log.
I am hoping to find a developer who is interested in helping OpenBSD update their ancient port (as there are other build failures after this). If anyone is interested, please drop me a private email on <edd at openbsd dot org>. Cheers.
NOTE, please don't ask me to try the hg tip, as the bootstrap process does not work on OpenBSD. I am unable to make a configure script. We can tackle this later.
|