You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2004/09/17 03:42:19 UTC
clean OSX build -- compile error.
I'm trying to get Subversion (and all dependencies) built from scratch
on a brand new OSX 10.3.5 machine. Can someone help me out?
Here's what I've done:
* installed the XCode 1.5 packages (gives me gcc 3.3 toolchain)
* built and installed neon-0.24.7 tarball
* built and installed bdb-4.2.52 tarball
* build and installed httpd-2.0.51 (pointing its apr-util to BDB, of
course)
* in my new working copy of /trunk, run ./configure and make.
I've seen no obvious errors at any point in this process, until gcc
tries to compile libsvn_subr/io.c.
The error is freaky to me, since it's dealing with darwin kernel
headers. Any OSX folks have a clue here?
/bin/sh /Users/sussman/projects/svn/libtool --silent --mode=compile gcc
-DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -g -g -Wall
-Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations
-DNEON_ZLIB -DNEON_SSL -DSVN_DEBUG -DAP_DEBUG -Wpointer-arith
-Wwrite-strings -Wshadow -std=c89 -I./subversion/include
-I./subversion -I/usr/local/include/neon -I/usr/local/apache2/include
-I/usr/local/apache2/include -I/usr/local/BerkeleyDB.4.2/include -o
subversion/libsvn_subr/io.lo -c subversion/libsvn_subr/io.c
In file included from /usr/include/libkern/OSByteOrder.h:35,
from /usr/include/architecture/byte_order.h:34,
from /usr/include/mach-o/loader.h:47,
from /usr/include/mach-o/dyld.h:34,
from /usr/local/apache2/include/apr_portable.h:162,
from subversion/libsvn_subr/io.c:48:
/usr/include/libkern/ppc/OSByteOrder.h:42: error: syntax error before
"uint16_t"
/usr/include/libkern/ppc/OSByteOrder.h:57: error: syntax error before
"uint32_t"
/usr/include/libkern/ppc/OSByteOrder.h:72: error: syntax error before
"uint64_t"
/usr/include/libkern/ppc/OSByteOrder.h:93: error: syntax error before
"void"
/usr/include/libkern/ppc/OSByteOrder.h:107: error: syntax error before
"void"
/usr/include/libkern/ppc/OSByteOrder.h:121: error: syntax error before
"void"
/usr/include/libkern/ppc/OSByteOrder.h:143: error: syntax error before
"uint16_t"
/usr/include/libkern/ppc/OSByteOrder.h:153: error: syntax error before
"uint32_t"
/usr/include/libkern/ppc/OSByteOrder.h:163: error: syntax error before
"uint64_t"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: clean OSX build -- compile error.
Posted by Bastian Blank <ba...@waldi.eu.org>.
On Thu, Sep 16, 2004 at 10:42:19PM -0500, Ben Collins-Sussman wrote:
> I've seen no obvious errors at any point in this process, until gcc
> tries to compile libsvn_subr/io.c.
> The error is freaky to me, since it's dealing with darwin kernel
> headers. Any OSX folks have a clue here?
My version of /usr/include/libkern/ppc/OSByteOrder.h prepends the
definitions by OS_INLINE, which seems to be defined somewhere else.
Bastian
--
Star Trek Lives!
Re: clean OSX build -- compile error.
Posted by Max Bowsher <ma...@ukf.net>.
Greg Hudson wrote:
> On Sat, 2004-09-18 at 12:10, Justin Erenkrantz wrote:
>> I don't know of a passable reason why 'std=c89' should be part of
>> maintainer
>> mode. That doesn't make much sense to me: it doesn't help *that* much.
>
> I believe we put it in because the vast majority of our trunk builds are
> done with gcc, such that we could use a gcc feature without realizing
> it.
>
> However, the gcc maintainers are pretty clear that -std=c89 is not an
> ANSI conformance checker. It really only disables the gcc features
> necessary to make ANSI-compliant code compile. For instance, you could
> have a local variable named "inline" in a valid C89 program, so -std=c89
> disables the "inline" keyword. So you're right, it doesn't help that
> much. If we added the -pedantic flag it might help a little more, but
> we'd have even more issues with header files not under our control.
>
>> I vote that we stop adding it in maintainer mode. -- justin
>
> Agreed (though my position here has always been clear).
Then perhaps we should be adding -pedantic in maintainer-mode, subject to an
autoconf test (similar to what we already have for -std=c89) which turns it
off if the system headers can't cope with it?
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: clean OSX build -- compile error.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Sat, 2004-09-18 at 12:10, Justin Erenkrantz wrote:
> I don't know of a passable reason why 'std=c89' should be part of maintainer
> mode. That doesn't make much sense to me: it doesn't help *that* much.
I believe we put it in because the vast majority of our trunk builds are
done with gcc, such that we could use a gcc feature without realizing
it.
However, the gcc maintainers are pretty clear that -std=c89 is not an
ANSI conformance checker. It really only disables the gcc features
necessary to make ANSI-compliant code compile. For instance, you could
have a local variable named "inline" in a valid C89 program, so -std=c89
disables the "inline" keyword. So you're right, it doesn't help that
much. If we added the -pedantic flag it might help a little more, but
we'd have even more issues with header files not under our control.
> I vote that we stop adding it in maintainer mode. -- justin
Agreed (though my position here has always been clear).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: clean OSX build -- compile error.
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, September 17, 2004 1:03 PM -0500 Ben Collins-Sussman
<su...@collab.net> wrote:
> Well, here's one more idea: just stop using '-std=c89'. :-)
I don't know of a passable reason why 'std=c89' should be part of maintainer
mode. That doesn't make much sense to me: it doesn't help *that* much.
I vote that we stop adding it in maintainer mode. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: clean OSX build -- compile error.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 17, 2004, at 12:28 PM, Ben Collins-Sussman wrote:
>
> Anyone have any thoughts? Better ideas?
>
Well, here's one more idea: just stop using '-std=c89'. :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: clean OSX build -- compile error.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 17, 2004, at 1:12 PM, Jim Correia wrote:
>
> Could be. If you have suspicious headers that you want to send me a
> tarball of off-list for diffing with what I've got, I'd be happy to do
> that and report back.
>
>
Maxb figured it out: the -std=c89 flag is only used when you
./configure --enable-maintainer-mode. You need the c89 flag *and* the
broken darwin header to trigger the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: clean OSX build -- compile error.
Posted by Jim Correia <ji...@pobox.com>.
On Sep 17, 2004, at 1:55 PM, Ben Collins-Sussman wrote:
> [keeping this on dev@ list]
>
> On Sep 17, 2004, at 12:43 PM, Jim Correia wrote:
>>
>> Does this problem only happen on trunk? I just tried to build the
>> 1.1RC3 tarball on a 10.3.5 machine with the Xcode 1.5 toolchain
>> (which was upgraded from 1.2, so it possible something got botched or
>> is different than a clean install) and it works fine.
>
> Hm, interesting. I wonder if your Xcode upgrade left the original 1.2
> /usr/include/libkern/ headers unchanged?
Could be. If you have suspicious headers that you want to send me a
tarball of off-list for diffing with what I've got, I'd be happy to do
that and report back.
You mentioned this is a new X box? What kind of hardware? What version
of the kernel does it have?
For reference, both of my 10.3.5 boxen report:
Darwin Kernel Version 7.5.0: Thu Aug 5 19:26:16 PDT 2004;
root:xnu/xnu-517.7.21.obj~3/RELEASE_PPC
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: clean OSX build -- compile error.
Posted by Ben Collins-Sussman <su...@collab.net>.
[keeping this on dev@ list]
On Sep 17, 2004, at 12:43 PM, Jim Correia wrote:
>
> Does this problem only happen on trunk? I just tried to build the
> 1.1RC3 tarball on a 10.3.5 machine with the Xcode 1.5 toolchain (which
> was upgraded from 1.2, so it possible something got botched or is
> different than a clean install) and it works fine.
Hm, interesting. I wonder if your Xcode upgrade left the original 1.2
/usr/include/libkern/ headers unchanged?
>
> The build was configured with
>
> ./configure --without-berkeley-db
>
> Does it require that I enable other things, like maintainer mode? Just
> trying to be helpful - it builds out of the box for me (which is a
> good thing :-).
>
Subversion unconditionally #includes "apr_portable.h", which is what
includes the broken darwin header, so I can't see how an svn
./configure switch should make a difference.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: clean OSX build -- compile error.
Posted by Ben Collins-Sussman <su...@collab.net>.
Okay, so it's definitely a bug in the latest toolchain headers shipped
by Apple. I filed a bug with them. If I insert this bit into a couple
of darwin kernel headers, Subversion compiles fine with the gcc
-std=c89 flag:
/* Temporary workaround for broken OSX system headers, shipped in
XCode 1.5. They're declaring stuff 'static inline', and this is
incompatible with the '-std=c89' flag we pass to gcc.
See Apple bug #3805571. */
#if defined(__APPLE__) && !defined(inline)
#define inline __inline__
#endif
So, sure, I could go and remove my toolchain and install an older one.
But that's not going to prepare us for the floods of bug reports that
come in once OSX developers start upgrading their own toolchains. I'm
just the first person to try to compile Subversion with the latest
stuff, others will follow soon. I think it's best to get a workaround
committed.
So I tried to put this workaround into various svn header files, but
it's no use. The bug is triggered by anything that #includes
<apr_portable.h>. And svn C files *always* include APR headers before
svn headers, for obvious reasons. So that means either:
* attaching this workaround to a handful of svn C files, or
* putting the patch in apr_portable.h, in the apr 0.9.x branch
Both of these options kinda stink. If we do the latter, we commit the
change to apr 0.9.x, then wait for apache 2.0.52? And post a patch in
the meantime? This is what we did with the bdb 4.2-detection patch for
apr-util way back when, and it was annoying.
Anyone have any thoughts? Better ideas?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: clean OSX build -- compile error.
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> > http://www.contactor.se/~dast/svn/archive-2003-06/1019.shtml
> >
> > I told you so.
>
> Ha. I agree about your "do what everyone else does" philosophy, but
> this is a standard gcc flag, isn't it? If we pass a legal flag to
> gcc, and the system kernel headers can't deal with it, I'd say that
> Apple has a bug here in their toolchain distribution. I'm gonna ping
> some Apple folks.
Greg's point isn't about whether the flag is legal. It's about
whether we really *need* to be passing it, whether passing it isn't
just asking for trouble. Like in the case you just encountered :-).
Sure it's a bug in Apple's configuration -- but we didn't have to
stimulate the bug. His point is that doing unusual things tends to
stimulate bugs like this.
I'm not doing anything constructive like suggesting a course of action
here, just trying to clarify Greg's point.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: clean OSX build -- compile error.
Posted by Jim Correia <ji...@pobox.com>.
On Sep 17, 2004, at 10:32 AM, Ben Collins-Sussman wrote:
> And fitz isn't able to reproduce this. I'm guessing my OS headers
> (the ones with the INLINE stuff) are newer than his.
I have not tried to build trunk. The 1.1RC3 tarball builds fine for me
on 10.3.5, but I'm still using the Xcode 1.2 toolchain.
% gcc -v
Reading specs from /usr/libexec/gcc/darwin/ppc/3.3/specs
Thread model: posix
gcc version 3.3 20030304 (Apple Computer, Inc. build 1640)
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: clean OSX build -- compile error.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 17, 2004, at 9:28 AM, Greg Hudson wrote:
> On Fri, 2004-09-17 at 08:54, Ben Collins-Sussman wrote:
>> Sure enough, if I remove our '-std=c89' option from the compile line
>> above, then io.c compiles just fine.
>
> http://www.contactor.se/~dast/svn/archive-2003-06/1019.shtml
>
> I told you so.
>
Ha. I agree about your "do what everyone else does" philosophy, but
this is a standard gcc flag, isn't it? If we pass a legal flag to gcc,
and the system kernel headers can't deal with it, I'd say that Apple
has a bug here in their toolchain distribution. I'm gonna ping some
Apple folks.
What's annoying is that even if I tell OSX to use gcc 3.1 instead of
gcc 3.3, I get the same error. And fitz isn't able to reproduce this.
I'm guessing my OS headers (the ones with the INLINE stuff) are newer
than his.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: clean OSX build -- compile error.
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2004-09-17 at 08:54, Ben Collins-Sussman wrote:
> Sure enough, if I remove our '-std=c89' option from the compile line
> above, then io.c compiles just fine.
http://www.contactor.se/~dast/svn/archive-2003-06/1019.shtml
I told you so.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: clean OSX build -- compile error.
Posted by Ben Collins-Sussman <su...@collab.net>.
On Sep 16, 2004, at 10:42 PM, Ben Collins-Sussman wrote:
>
> /bin/sh /Users/sussman/projects/svn/libtool --silent --mode=compile
> gcc -DDARWIN -DSIGPROCMASK_SETS_THREAD_MASK -no-cpp-precomp -g -g
> -Wall -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations
> -DNEON_ZLIB -DNEON_SSL -DSVN_DEBUG -DAP_DEBUG -Wpointer-arith
> -Wwrite-strings -Wshadow -std=c89 -I./subversion/include
> -I./subversion -I/usr/local/include/neon -I/usr/local/apache2/include
> -I/usr/local/apache2/include -I/usr/local/BerkeleyDB.4.2/include -o
> subversion/libsvn_subr/io.lo -c subversion/libsvn_subr/io.c
> In file included from /usr/include/libkern/OSByteOrder.h:35,
> from /usr/include/architecture/byte_order.h:34,
> from /usr/include/mach-o/loader.h:47,
> from /usr/include/mach-o/dyld.h:34,
> from /usr/local/apache2/include/apr_portable.h:162,
> from subversion/libsvn_subr/io.c:48:
> /usr/include/libkern/ppc/OSByteOrder.h:42: error: syntax error before
> "uint16_t"
> /usr/include/libkern/ppc/OSByteOrder.h:57: error: syntax error before
> "uint32_t"
> /usr/include/libkern/ppc/OSByteOrder.h:72: error: syntax error before
> "uint64_t"
> /usr/include/libkern/ppc/OSByteOrder.h:93: error: syntax error before
> "void"
> /usr/include/libkern/ppc/OSByteOrder.h:107: error: syntax error before
> "void"
> /usr/include/libkern/ppc/OSByteOrder.h:121: error: syntax error before
> "void"
> /usr/include/libkern/ppc/OSByteOrder.h:143: error: syntax error before
> "uint16_t"
> /usr/include/libkern/ppc/OSByteOrder.h:153: error: syntax error before
> "uint32_t"
> /usr/include/libkern/ppc/OSByteOrder.h:163: error: syntax error before
> "uint64_t"
>
Well, googling for this error led to an interesting discovery.
At this link:
http://forums.macosxhints.com/archive/index.php/t-19270
...it's suggested that these errors are happening in the kernel headers
whereever things are declared 'inline', and that this is incompatible
with gcc 3.3's -ansi option.
Sure enough, if I remove our '-std=c89' option from the compile line
above, then io.c compiles just fine.
This is perplexing to me. I don't think Subversion is doing anything
wrong, is it? Is this perhaps some sort of bug in the latest OSX GNU
toolchain?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org