You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Andreas Krey <a....@gmx.de> on 2011/10/18 21:53:31 UTC
1.7.0 does not build on Solaris9
When building subversion 1.7.0 on Solaris9 I get a strange error:
/bin/bash /export/home/krey/sub1.7.0/libtool --tag=CC --silent --mode=compile gcc -DSOLARIS2=9 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE -g -O2 -g -O2 -pthreads -D_LARGEFILE64_SOURCE -DNE_LFS -I./subversion/include -I./subversion -I/export/home/krey/sub1.7.0/apr/include -I/export/home/krey/sub1.7.0/apr-util/include -I/usr/local/include/neon -I./serf -I/export/home/krey/sub1.7.0/sqlite-amalgamation -o subversion/libsvn_subr/simple_providers.lo -c subversion/libsvn_subr/simple_providers.c
/bin/bash /export/home/krey/sub1.7.0/libtool --tag=CC --silent --mode=compile gcc -DSOLARIS2=9 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE -g -O2 -g -O2 -pthreads -D_LARGEFILE64_SOURCE -DNE_LFS -I./subversion/include -I./subversion -I/export/home/krey/sub1.7.0/apr/include -I/export/home/krey/sub1.7.0/apr-util/include -I/usr/local/include/neon -I./serf -I/export/home/krey/sub1.7.0/sqlite-amalgamation -o subversion/libsvn_subr/skel.lo -c subversion/libsvn_subr/skel.c
/bin/bash /export/home/krey/sub1.7.0/libtool --tag=CC --silent --mode=compile gcc -DSOLARIS2=9 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE64_SOURCE -g -O2 -g -O2 -pthreads -D_LARGEFILE64_SOURCE -DNE_LFS -I./subversion/include -I./subversion -I/export/home/krey/sub1.7.0/apr/include -I/export/home/krey/sub1.7.0/apr-util/include -I/usr/local/include/neon -I./serf -I/export/home/krey/sub1.7.0/sqlite-amalgamation -o subversion/libsvn_subr/sorts.lo -c subversion/libsvn_subr/sorts.c
none ./build/transform_sql.py subversion/libsvn_subr/internal_statements.sql ./subversion/libsvn_subr/internal_statements.h
/bin/bash: none: command not found
make: *** [subversion/libsvn_subr/internal_statements.h] Error 127
It seems that ./configure does not know enough about this kind of system,
or does libtool? Or is there missing a check for 'none'?
[Build from subversion-1.7.0.tar.bz2 plus what get-deps.sh drags in;
the dragging being done on another machine.]
How do I get to compile that?
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: 1.7.0 does not build on Solaris9
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Andreas Krey wrote on Wed, Oct 19, 2011 at 12:08:18 +0200:
> ldd already tells me the line 'libz.so => /usr/lib/libz.so'
> which is a bit irritating because why did get-deps pull zlib in the
> first place when it uses the system one?
Looking at build/ac-macros/zlib.m4 I don't see any special handling for
checking if zlib exists at ./zlib (like we check for some other
dependencies).
Probably an oversight.
Re: 1.7.0 does not build on Solaris9
Posted by Andreas Krey <a....@gmx.de>.
On Wed, 19 Oct 2011 10:36:28 +0000, Philip Martin wrote:
> Andreas Krey <a....@gmx.de> writes:
...
> I think that is a zlib symbol. Subversion links some libraries against
> zlib but doesn't link executables to zlib directly, relying on the
> library to pull them in. If you build using
>
> make EXTRA_LDFLAGS=-lz
ldd already tells me the line 'libz.so => /usr/lib/libz.so'
which is a bit irritating because why did get-deps pull zlib in the
first place when it uses the system one?
/usr/lib/libz.so does not seem to have any symbol containing 'Bound',
thus probably being before 1.2.0.
> make EXTRA_LDFLAGS='-lz -L/some/dir'
That will be useful for -lintl.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: 1.7.0 does not build on Solaris9
Posted by Philip Martin <ph...@wandisco.com>.
Andreas Krey <a....@gmx.de> writes:
> + svn commit -m 1
> Adding kadr.polon.p
> Transmitting file data .ld.so.1: svn: fatal: relocation error: file /export/home/krey/svn17/lib/libsvn_delta-1.so.0: symbol compressBound: referenced symbol not found
I think that is a zlib symbol. Subversion links some libraries against
zlib but doesn't link executables to zlib directly, relying on the
library to pull them in. If you build using
make EXTRA_LDFLAGS=-lz
that will probably fix the problem. If zlib is in some non-standard
location you may need
make EXTRA_LDFLAGS='-lz -L/some/dir'
--
Philip
Re: 1.7.0 does not build on Solaris9
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Andreas Krey wrote on Wed, Oct 19, 2011 at 08:19:29 +0200:
> On Tue, 18 Oct 2011 23:21:12 +0000, Daniel Shahaf wrote:
> > Andreas Krey wrote on Tue, Oct 18, 2011 at 23:15:29 +0200:
> > > On Tue, 18 Oct 2011 22:12:47 +0000, Daniel Shahaf wrote:
> > > ...
> > > > - those foo.h file generated from foo.sql files are supposed to be
> > > > pre-generated in the tarball
> > >
> > > They are. Except that I copied over the tree, and the timestamps
> > > afterwards were so that it tought it necessary to recreate. Ouch.
> > >
> >
> > Is there something we can do in the release process to help avoid this?
>
> You would need to remove the build rules for the .h files in the
> makefile when you ship the tar file. A bit complicated. (And who
> does not work directly from an unpacked tarfile and instead copy
> it around?. I did because the target machine has no direct inet
> access and now wget or simile.) A note in the INSTALL would be
> simpler, I guess.
>
> Anyway, the build still has some other issues (sqlite ftruncate, -lintl),
> but they can be overcome.
>
Actually it's not as hard as it sounds. For creating tarballs we run
autogen.sh with a specific argument; and the relevant makefile rules are
generated by build.conf rules. So, it's conceiveable we could
autogen.sh invoke [the tool that uses] build.conf in a way that say,
"Drop those Makefile rules".
I haven't paused to think if it's a good idea, by the way, I'm just
flowing along with your suggestion.
> ...
> > > + svnadmin create repo
> > > svnadmin: Version mismatch in 'svn_delta': found 1.5.5, expected 1.7.0
> ...
> > Did you build with debug or maintainer flags?
>
> No; actually I was stupid...
>
> > ldd svnadmin
>
> which shows me that it links to the old .so files, which in turn
> indicates that I made a minor mistake in setting LD_LIBRARY_PATH.
> (Unfortunately that seems to take precedence over what -r told
> the linker.)
>
> Now it fails differently:
>
> + svn commit -m 1
> Adding kadr.polon.p
> Transmitting file data .ld.so.1: svn: fatal: relocation error: file /export/home/krey/svn17/lib/libsvn_delta-1.so.0: symbol compressBound: referenced symbol not found
>
That's a symbol from zlib, used by the svndiff1 code. If you don't want
to do the ldd dance again then 'svnadmin create --pre-1.4-compatible'
might workaround the error.
> > (or 'libtool --mode=execute ldd ./subversion/svnadmin/svnadmin', if
> > svnadmin is a libtool wrapper.)
>
> What is this libtool good for, anyway? Looks like it isn't really
> doing anything.
In this case it allows running the in-tree executables against the
in-tree libraries. Yes, it receives some criticism from time to time.
Re: 1.7.0 does not build on Solaris9
Posted by Andreas Krey <a....@gmx.de>.
On Tue, 18 Oct 2011 23:21:12 +0000, Daniel Shahaf wrote:
> Andreas Krey wrote on Tue, Oct 18, 2011 at 23:15:29 +0200:
> > On Tue, 18 Oct 2011 22:12:47 +0000, Daniel Shahaf wrote:
> > ...
> > > - those foo.h file generated from foo.sql files are supposed to be
> > > pre-generated in the tarball
> >
> > They are. Except that I copied over the tree, and the timestamps
> > afterwards were so that it tought it necessary to recreate. Ouch.
> >
>
> Is there something we can do in the release process to help avoid this?
You would need to remove the build rules for the .h files in the
makefile when you ship the tar file. A bit complicated. (And who
does not work directly from an unpacked tarfile and instead copy
it around?. I did because the target machine has no direct inet
access and now wget or simile.) A note in the INSTALL would be
simpler, I guess.
Anyway, the build still has some other issues (sqlite ftruncate, -lintl),
but they can be overcome.
...
> > + svnadmin create repo
> > svnadmin: Version mismatch in 'svn_delta': found 1.5.5, expected 1.7.0
...
> Did you build with debug or maintainer flags?
No; actually I was stupid...
> ldd svnadmin
which shows me that it links to the old .so files, which in turn
indicates that I made a minor mistake in setting LD_LIBRARY_PATH.
(Unfortunately that seems to take precedence over what -r told
the linker.)
Now it fails differently:
+ svn commit -m 1
Adding kadr.polon.p
Transmitting file data .ld.so.1: svn: fatal: relocation error: file /export/home/krey/svn17/lib/libsvn_delta-1.so.0: symbol compressBound: referenced symbol not found
> (or 'libtool --mode=execute ldd ./subversion/svnadmin/svnadmin', if
> svnadmin is a libtool wrapper.)
What is this libtool good for, anyway? Looks like it isn't really
doing anything.
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: 1.7.0 does not build on Solaris9
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Andreas Krey wrote on Tue, Oct 18, 2011 at 23:15:29 +0200:
> On Tue, 18 Oct 2011 22:12:47 +0000, Daniel Shahaf wrote:
> ...
> > - those foo.h file generated from foo.sql files are supposed to be
> > pre-generated in the tarball
>
> They are. Except that I copied over the tree, and the timestamps
> afterwards were so that it tought it necessary to recreate. Ouch.
>
Is there something we can do in the release process to help avoid this?
> Ok, after an '#include <unistd.h>' in the sqlite amalg (for ftruncate),
> a few touches on the generated .h, and re-invoking the linker commands
> (quite a few) with an -lintl added, I seem to have a binary.
>
> But svnadmin greets me with:
>
> + svnadmin create repo
> svnadmin: Version mismatch in 'svn_delta': found 1.5.5, expected 1.7.0
> svnadmin: Version mismatch in 'svn_fs': found 1.5.5, expected 1.7.0
> svnadmin: Version mismatch in 'svn_repos': found 1.5.5, expected 1.7.0
> svnadmin: Version mismatch in 'svn_subr': found 1.5.5, expected 1.7.0
>
Did you build with debug or maintainer flags?
ldd svnadmin
(or 'libtool --mode=execute ldd ./subversion/svnadmin/svnadmin', if
svnadmin is a libtool wrapper.)
Re: 1.7.0 does not build on Solaris9
Posted by Andreas Krey <a....@gmx.de>.
On Tue, 18 Oct 2011 22:12:47 +0000, Daniel Shahaf wrote:
...
> - those foo.h file generated from foo.sql files are supposed to be
> pre-generated in the tarball
They are. Except that I copied over the tree, and the timestamps
afterwards were so that it tought it necessary to recreate. Ouch.
Ok, after an '#include <unistd.h>' in the sqlite amalg (for ftruncate),
a few touches on the generated .h, and re-invoking the linker commands
(quite a few) with an -lintl added, I seem to have a binary.
But svnadmin greets me with:
+ svnadmin create repo
svnadmin: Version mismatch in 'svn_delta': found 1.5.5, expected 1.7.0
svnadmin: Version mismatch in 'svn_fs': found 1.5.5, expected 1.7.0
svnadmin: Version mismatch in 'svn_repos': found 1.5.5, expected 1.7.0
svnadmin: Version mismatch in 'svn_subr': found 1.5.5, expected 1.7.0
:-(
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800
Re: 1.7.0 does not build on Solaris9
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Andreas Krey wrote on Tue, Oct 18, 2011 at 21:58:27 +0200:
> On Tue, 18 Oct 2011 21:53:31 +0000, Andreas Krey wrote:
> ...
> > none ./build/transform_sql.py subversion/libsvn_subr/internal_statements.sql ./subversion/libsvn_subr/internal_statements.h
>
> Hmm. Actually it seems tht that the python detection is skimpy.
> Is that required?
When building from a tarball
- Python is not required
- autogen.sh is not supposed to be run
- those foo.h file generated from foo.sql files are supposed to be
pre-generated in the tarball
Re: 1.7.0 does not build on Solaris9
Posted by Andreas Krey <a....@gmx.de>.
On Tue, 18 Oct 2011 21:53:31 +0000, Andreas Krey wrote:
...
> none ./build/transform_sql.py subversion/libsvn_subr/internal_statements.sql ./subversion/libsvn_subr/internal_statements.h
Hmm. Actually it seems tht that the python detection is skimpy.
Is that required?
Andreas
--
"Totally trivial. Famous last words."
From: Linus Torvalds <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800