RPM Community Forums

Mailing List Message of <rpm-devel>

Re: Status quo on my build environment anti-convolution efforts

From: Jason Corley <jason.corley@gmail.com>
Date: Wed 27 Jun 2007 - 22:43:43 CEST
Message-ID: <3118d8de0706271343k2419eb6dvfd0da6ee6ecd811e@mail.gmail.com>
This isn't what I would call glamorous work (I share JBJ's desire to
know as little about autoconf as possible) but it doesn't have to be
thankless.  So I at least would like to publicly thank you for this
tedious but important work.  Here's to progress. :-)
Jason

On 6/27/07, Ralf S. Engelschall <rse+rpm-devel@rpm5.org> wrote:
> On Wed, Jun 27, 2007, Ralf S. Engelschall wrote:
>
> > [...]
> > 2. Although we finally have a sophisticated way to link against
> >    the third-party libraries, we still have a related problem: the
> >    internal copies of third-party libraries are linked differently
> >    against RPM. "db" is packed directly into "librpmdb.la", "lua" by
> >    accident is packed into "librpm.la", etc. All not consistent and
> >    hence confusing and on some platforms even causing problems (Jeff
> >    for instance got failures with the Lua linking).
> >
> >    Here I've to investigate, too. I'm still not sure what the best
> >    approach is, but it should be clear that although the local copies of
> >    third-party libraries are not explicitly _installed_ (as libdb.la,
> >    liblua.la, etc) their _content_ has to be installed in some way or
> >    our librpm*.la are useless in practice. The approach of librpmdb.la
> >    to include libdb.la seems to be a ticky and acceptable solution
> >    although it has to be done for _all_ libraries and perhaps the
> >    third-party stuff should be grouped together (perhaps even in the new
> >    librpmmisc.la which is some sort of a container for remaining and
> >    dynamically selected stuff anyway). I'll look what I can do for us...
>
> After many hours thinking backward and forward, poking around in
> Automake documentation and performing stand-alone tests under
> FreeBSD 6 and Fedora 7 I finally think I've found a both clean,
> straight-forward and still fully portable solution to this mess.
> Berkeley-DB is now handled equally to all other internal third-party
> libs like Lua, File and ZLib and installed via a central bundling into
> librpmmisc. And the build-environment now no longer mixes the build
> flags of external and internal libraries (what caused the initial
> build problems for Jeff after RPM_CHECK_LIB was introduced). See
> http://rpm5.org/cvs/chngview?cn=7558 for details.
>
> I was now again able to cleanly build and install and test-run
> RPM 5 under FreeBSD 6 and Fedora 7 under both --enable-shared and
> --disable-shared and with and without a mixture of internal and external
> libraries. Under FreeBSD 6 I mostly built with --disable-shared and with
> dozend of uninstalled external libraries while under Fedora 7 I used
> system-installed versions for all the external libraries and built RPM
> with --enable-shared. Everything wors fine (again) now -- but this time
> we have a larger bunch of nasty hacks less in the build environment
> and a lot of new flexibility as my different tests under FreeBSD 6 and
> Fedora 7 show ;-)
>
>                                        Ralf S. Engelschall
>                                        rse@engelschall.com
>                                        www.engelschall.com
>
> ______________________________________________________________________
> RPM Package Manager                                    http://rpm5.org
> Developer Communication List                        rpm-devel@rpm5.org
>
Received on Wed Jun 27 22:43:46 2007
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.