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.
Received on 2011-10-19 11:35:33 CEST