Gentoo Archives: gentoo-alt

From: Michael Haubenwallner <haubi@g.o>
To: gentoo-alt@l.g.o
Cc: drizzt@g.o
Subject: Re: [gentoo-alt] Re: gnulib.eclass implementation
Date: Thu, 05 Mar 2009 14:00:17
Message-Id: 1236261582.26290.1.camel@salomon-22
In Reply to: [gentoo-alt] Re: gnulib.eclass implementation by Fabian Groffen
On Wed, 2009-03-04 at 19:00 +0100, Fabian Groffen wrote:
> On 04-03-2009 18:47:43 +0100, Timothy Redaelli wrote: > > I start to implement a gnulib.eclass that allows to include the modules that > > the ebuild wants. > > > > IMHO it's better than the pre-compiled libgnu.a with some modules, since we > > cannot know if an ebuild wants another module. > > At one point we just went for this and decided to just extend gnulib > with a version bump if needed.
One point was that often there are the same few modules missing for several packages, so building the same thing always feels unnecessary. Instead add new missing modules to the installed libgnu.a. (feels like: everyone uses preinstalled glibc and doesn't configure a private one ...) My first intention was to build *all* available gnulib modules, but this turned out to not work, IIRC because of gnulib-bugs in some modules. So I switched to building the required ones only. More points to keep in mind: *) libgnu.a (from ebuild, either preinstalled or not) is for packages without any portability bits and thus _not_ shipping with any gnulib modules at all, expecting them from the host os. As of now, haven't seen too many of them yet, at least not in @system. Usually these are distro-specific packages like portage-utils only. *) libgnu.a does not work with packages already shipping with some gnulib modules when they just forgot to add another one. *) Maybe we want a shared libgnu some day, to ease distributing fixes in gnulib modules.
> > DEPEND=" > > - ppc-aix? ( dev-libs/gnulib ) > > - sparc-solaris? ( dev-libs/gnulib ) > > - sparc64-solaris? ( dev-libs/gnulib ) > > - x86-solaris? ( dev-libs/gnulib ) > > - x64-solaris? ( dev-libs/gnulib ) > > + ppc-aix? ( >=dev-libs/gnulib-2009.03.03.14.07.45 ) > > + sparc-solaris? ( >=dev-libs/gnulib-2009.03.03.14.07.45 ) > > + sparc64-solaris? ( >=dev-libs/gnulib-2009.03.03.14.07.45 ) > > + x86-solaris? ( >=dev-libs/gnulib-2009.03.03.14.07.45 ) > > + x64-solaris? ( >=dev-libs/gnulib-2009.03.03.14.07.45 ) > > "
As gnulib detects itself if a replacement implementation actually is necessary, this results in an empty libgnu.a on glibc-platforms - still providing some headers causing warnings when using unportable functions. So maybe we want to depend on dev-libs/gnulib unconditionally in the offending packages?
> > - if [[ ${CHOST} == *-aix* || ${CHOST} == *-solaris* ]]; then > > - append-flags -I"${EPREFIX}"/usr/$(get_libdir)/gnulib/include > > - append-ldflags -L"${EPREFIX}"/usr/$(get_libdir)/gnulib/lib > > - append-libs -lgnu > > - fi
+1 for having this in an eclass-function - maybe unconditional, as using gnulib modules can require slightly different sourcecode (like including different headers). We just didn't do that yet because there aren't so many packages where libgnu.a really helps. When I stopped with portage-utils for solaris9, IIRC it required scandir&co, which was (is?) missing in gnulib[1]. But things seem to have changed since. [1] http://lists.gnu.org/archive/html/bug-gnulib/2008-09/msg00148.html /haubi/ -- Michael Haubenwallner Gentoo on a different level