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.
