Jeffrey Johnson wrote:
>> I don't think changing devtool.conf to a db version that actually
>> exists/works is going to change that, but thanks for the warning.
>>
>> ./rpmdb/rpmdb.h:435: error: expected specifier-qualifier-list before
>> 'DB_SEQUENCE'
>> ./rpmdb/rpmdb.h:492: error: expected specifier-qualifier-list before
>> 'DB_LOGC'
>>
>
> Yes there are many BDB build failures because I target a single version of
> Berkeley DB (currently db-5.3.15) and am not bothering to express the
> myriad path divergences carefully. E.g. something like this
> is needed on *BSD systems:
> --with-db=${prefix}/include/db53:${prefix}/lib/db53
> and its just simpler for me to do this hack-o-round instead under buildbot's:
> cd ${prefix}/lib
> ln -s db53/* .
> so that I can juggle the devtool.conf build options more easily.
Right, just that the configuration (and installation instructions)
still said "5.1 or later" (that is: db51) which doesn't compile now ?
> And yes --with-dbsql makes it even more snarly, but its basically
> the same approach.
>
> And yes there's likely a bit more to do to achieve Just Works for
> RPM finding Berkeley DB in all the dark corners in which it is hidden.
Right, and I suppose the renaming of db52 to "db5" didn't help...
Or that you can't depend on sql being there, since it's an "option".
> But I likely should try to make your life on MacPorts and *BSD easier. todo++.
There's always the going back to internal, hopefully not needed.
But currently it doesn't work on FreeBSD, unless upgrading db5.
>> There was some issue with the (ancient) default perl5.8 in MacPorts
>> not liking -rpath, but fixed it in the port. Otherwise 5.4.8 was OK.
>>
>
> Yes: I could use some OS X expertise here.
>
> In order to attempt "use perl" and "use URPM" from the embedded perl
> interpreter, I had to solve the problem of module -> library linkage.
>
> I initially slammed in a LD_LIBRARY_PATH envvar with all the just built
> libraries. That got me the ability to do
> make -C perl check
> without doing the installation.
>
> After some further thought, I figured out the @ORIGIN internal ELF equivalent
> of
> LD_LIBRARY_PATH and did this instead (perl/Makefile.PL tweaks):
>
> # use $ORIGIN relative paths to avoid LD_LIBRARY_PATH nonsense in tree
> my @ldaddr = map { '-Wl,-rpath,\$$\ORIGIN/../../../../../' . $_ . '/.libs'
> } @libdir;
>
> so that the perl module could find just built libraries easily. This is
> essentially
> a reimplementation the hard way for what ./libtool does more elegantly in
> AutoFu.
>
> Using $ORIGIN introduced some mild risk of exploits (but could be handled
> by relinking or running chrpath when installing), but otherwise "works"
> nicely.
>
> Until I get to Mac OS X where $ORIGIN wasn't implemented in 10.3 and I have
> a FULLSTOP build failure.
>
> Is overriding the Xcode mandated (afaik) 10.3 "compatibility" in Makefile.PL
> the right approach here? Or back to LD_LIBRARY_PATH?
I think back to LD_LIBRARY_PATH is the "easiest", though it's called
DYLD_LIBRARY_PATH so darwin needs to be special-cased anyway.
The reason why it doesn't work with the -rpath is because the linker sets
MACOSX_DEPLOYMENT_TARGET=10.3 to get two-level namespaces.
But it only checks for darwins 5 through 8, so doesn't handle Leopard on...
Ever since Intel arrived, the minimum target has been 10.4 always anyway.
The Apple Perl is patched, so that it doesn't do that anymore: (perl5.12 -V)
ld='llvm-gcc-4.2 -mmacosx-version-min=10.7', ldflags ='-arch x86_64 -arch
i386 -fstack-protector -L/usr/local/lib'
But MacPorts just has to use their own (unpatched) perl, and thus you get:
ld='env MACOSX_DEPLOYMENT_TARGET=10.3 /Developer/usr/bin/clang', ldflags
='-L/opt/local/lib -fstack-protector'
The patch in question is:
ed - $(PROJECT)/hints/darwin.sh < fix/darwin.sh.ed && \
http://opensource.apple.com/source/perl/perl-73/5.12/fix/darwin.sh.ed?txt
Which makes all modules work for the local OS version and later (only)...
But the Perl and Python etc module compile flags belong to the interpreter,
so one really should patch those instead of overriding them when building.
(this also goes for packages that mistakenly replace them with the optflags)
Maybe not the arch flags, but anyway. (both default to building fat binaries)
Another thing that is somewhat problematic is that there are two of each one,
and it's tricky to build both without having to reconfigure and rebuild rpm too.
i.e. there's perl5.10 and perl5.12, plus python2.6 and python2.7, in /usr/bin.
(MacPorts is even worse, it currently includes 4 versions of each interpreter)
> Short answer:
> Turn on --with-perl on OS X and you SHOULD see the issue instantly.
Yes, saw it when upgraded. My workaround was disabling the added -rpath.
That stops it from working in-tree, but should still be OK when in the prefix ?
>> There is no db53 in FreeBSD Ports yet, and they have removed the
>> minor version so the port is now db5 (currently at version 5.2.42)
>>
>
> Yes. It gets worse with
> --with-libgit2=internal
> which almost but not quite bundles libgit2 checkout from github into
> -lrpmmisc. The issue is _ENTIRELY_ lack of *.la file generation in
> libgit2.
>
> Oddly the easiest path to "fix" in order to use -lgit2 is to re-import
> the GIT code into CVS and whack in *.la files so that
> --with-libgit2=internal
> bundles libgit2 into -lrpmmisc correctly, no fuss, no muss.
>
> Isn't it ironic? RPM needs to put libgit2 into CVS and add *.la in order to
> use, sigh.
Not more ironic than the traditional deleting of every *.la file on sight...
(static linking and internal bundling isn't very popular, with the distros)
I do blame CMake. But couldn't you use pkg-config, and the libgit2.pc ?
Though the .pc only added -lz -lcrypto. Not sure what the problem was.
--anders
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
