Gentoo Logo
Gentoo Spaceship




Note: Due to technical difficulties, the Archives are currently not up to date. GMANE provides an alternative service for most mailing lists.
c.f. bug 424647
List Archive: gentoo-alt
Navigation:
Lists: gentoo-alt: < Prev By Thread Next > < Prev By Date Next >
Headers:
To: gentoo-alt@g.o
From: Michael Haubenwallner <haubi@g.o>
Subject: Re: Re: gnulib.eclass implementation
Date: Thu, 05 Mar 2009 14:59:42 +0100
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



References:
Re: gnulib.eclass implementation
-- Fabian Groffen
Navigation:
Lists: gentoo-alt: < Prev By Thread Next > < Prev By Date Next >
Previous by thread:
Re: gnulib.eclass implementation
Next by thread:
Bootstrap issues on Mac
Previous by date:
Re: gnulib.eclass implementation
Next by date:
Bootstrap issues on Mac


Updated Jun 17, 2009

Summary: Archive of the gentoo-alt mailing list.

Donate to support our development efforts.

Copyright 2001-2013 Gentoo Foundation, Inc. Questions, Comments? Contact us.