[gentoo-dev] GlibC

[gentoo-dev] GlibC

[Mathijs Kwik (-=TRoXX=-)]

Safe upgrading? :)

I tried 2 things which both fail...
using build-tarball:
changing the bootstrap-file to use glibc-2.2.3-r1 instead of 2.2.3
the build-tarball has 2.2.3-r1 allready installed so installing 2.2.3 would
be stupid(but it's still in the bootstrap-file).

and i also tried installing 2.2.3-r1 on a system with system=tarball
extracted... which also has 2.2.3-r1 in it.


so in both those cases I 'upgrade' a package to itself.
and in both cases it breaks everything on the system...
I don't know what exactly happens on the build-system.
but on the system-system(wow:) I end up having a 0-byte libc-2.2.3.so

so I don't know why this is... it's very easy to regenerate te error (did it
a few times, I thought it was just me:)

so either portage has a buggy, or glibc 2.2.3-r1.ebuild is buggy (because I
never got it to build+installed using portage).

please fix this or help me :)


---


another small thing I don't like (and I'm not the only one, I spoke some
guys on #gentoo who think the same)
the portage-tree is TOOOO big :)
there are things in it like diffs(some quite big) and even the
logo-header-file(almost 2M).
can't we just put all files/* stuff in a separate place on ibiblio/cvs and
put them in ebuild-files? (or let portage check if there are any
diffs/patches/additions)
I mean the portage-tree should just contain enough info to download+build
everything...
having diff's in there for packages that I'm not gonna install anyway seems
useless to me.

It's about 20M now... should be possible to reduce it to 2Mb :)
not because of bandwith, just for clean design.
Some others DO care about bandwith, which I can understand also.


Greetings
/Mathijs

Re: [gentoo-dev] GlibC

[Collins Richey]

I don't have access to my archive right now, but I remember that Achim said
you need to update the compiler before trying to update glibc.

--
Collins Richey
Denver area

----- Original Message -----
From: "Mathijs Kwik (-=TRoXX=-)" <troxx@segfault.nl>
To: <gentoo-dev@cvs.gentoo.org>
Sent: Tuesday, June 05, 2001 7:20 AM
Subject: [gentoo-dev] GlibC


> Safe upgrading? :)
>
> I tried 2 things which both fail...
> using build-tarball:
> changing the bootstrap-file to use glibc-2.2.3-r1 instead of 2.2.3
> the build-tarball has 2.2.3-r1 allready installed so installing 2.2.3
would
> be stupid(but it's still in the bootstrap-file).
>
> and i also tried installing 2.2.3-r1 on a system with system=tarball
> extracted... which also has 2.2.3-r1 in it.
>
>
> so in both those cases I 'upgrade' a package to itself.
> and in both cases it breaks everything on the system...
> I don't know what exactly happens on the build-system.
> but on the system-system(wow:) I end up having a 0-byte libc-2.2.3.so
>
> so I don't know why this is... it's very easy to regenerate te error (did
it
> a few times, I thought it was just me:)
>
> so either portage has a buggy, or glibc 2.2.3-r1.ebuild is buggy (because
I
> never got it to build+installed using portage).
>
> please fix this or help me :)
>
>
> ---
>
>
> another small thing I don't like (and I'm not the only one, I spoke some
> guys on #gentoo who think the same)
> the portage-tree is TOOOO big :)
> there are things in it like diffs(some quite big) and even the
> logo-header-file(almost 2M).
> can't we just put all files/* stuff in a separate place on ibiblio/cvs and
> put them in ebuild-files? (or let portage check if there are any
> diffs/patches/additions)
> I mean the portage-tree should just contain enough info to download+build
> everything...
> having diff's in there for packages that I'm not gonna install anyway
seems
> useless to me.
>
> It's about 20M now... should be possible to reduce it to 2Mb :)
> not because of bandwith, just for clean design.
> Some others DO care about bandwith, which I can understand also.
>
>
> Greetings
> /Mathijs
>
>
>
> _______________________________________________
> gentoo-dev mailing list
> gentoo-dev@cvs.gentoo.org
> http://cvs.gentoo.org/mailman/listinfo/gentoo-dev

[gentoo-dev] glibc

[Christian Loitsch]

don't know if you heard already: glibc-2.2.5 is out!
There is surprisingly little press about that.  (and their homepage isn't even
updated)

cu
christian

[gentoo-dev] glibc

[Steven Lucy]

perhaps the ebuild could do some filtering for this kind of thing, or is
there a good reason why it shouldn't?:

checking LD_LIBRARY_PATH variable... contains current directory
configure: error: 
*** LD_LIBRARY_PATH shouldn't contain the current directory when
*** building glibc. Please change the environment variable
*** and run configure again.

!!! ERROR: sys-libs/glibc-2.3.1-r2 failed.
!!! Function src_compile, Line 61, Exitcode 1
!!! (no error message)


Steven

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] glibc

[Nicholas Hockey]

[-- Attachment #1.1: Type: text/plain, Size: 1176 bytes --]

unset LD_LIBRARY_PATH and try re-emerging glibc

On Wed, 2003-01-29 at 19:38, Steven Lucy wrote:

> perhaps the ebuild could do some filtering for this kind of thing, or is
> there a good reason why it shouldn't?:
> 
> checking LD_LIBRARY_PATH variable... contains current directory
> configure: error: 
> *** LD_LIBRARY_PATH shouldn't contain the current directory when
> *** building glibc. Please change the environment variable
> *** and run configure again.
> 
> !!! ERROR: sys-libs/glibc-2.3.1-r2 failed.
> !!! Function src_compile, Line 61, Exitcode 1
> !!! (no error message)
> 
> 
> Steven
> 
> --
> gentoo-dev@gentoo.org mailing list

-- 
Nicholas Hockey (Tilt) <tilt@bluecherry.net>
Unix Administrator
Tilt@EFnet #BitchX
-------------------------------------------------------------------- 
GnuPG KeyID 4EDE2B84
Key fingerprint = B916 6032 BE3D 490D 2A08  F1BC 948A A4C1 4EDE 2B84
gpg --keyserver pgp.mit.edu --recv-keys 4EDE2B84
Or, if you perfer ldap (which i do, beacuse of the HKP protocol bug):
gpg --keyserver ldap://keyserver.pgp.com --recv-keys 4EDE2B84
--------------------------------------------------------------------

[-- Attachment #1.2: Type: text/html, Size: 1627 bytes --]

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] glibc

[Steven Lucy]

On Wed, Jan 29, 2003 at 10:40:01PM -0500, Nicholas Hockey <tilt@bluecherry.net> said
> unset LD_LIBRARY_PATH and try re-emerging glibc

of course that's what i did, i was just suggesting that the ebuild could do
this for you...

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] glibc

[Martin Schlemmer]

On Wed, 29 Jan 2003 22:20:41 -0600
Steven Lucy <slucy@uchicago.edu> wrote:

> On Wed, Jan 29, 2003 at 10:40:01PM -0500, Nicholas Hockey
> <tilt@bluecherry.net> said
> > unset LD_LIBRARY_PATH and try re-emerging glibc
> 
> of course that's what i did, i was just suggesting that the ebuild
> could do this for you...
> 

Why should it if the ./configure script handles it nicely ? =)


-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] glibc

[Matt Tucker]

-- Martin Schlemmer <azarah@gentoo.org> spake thusly:

> On Wed, 29 Jan 2003 22:20:41 -0600
> Steven Lucy <slucy@uchicago.edu> wrote:
> 
>> On Wed, Jan 29, 2003 at 10:40:01PM -0500, Nicholas Hockey
>> <tilt@bluecherry.net> said
>> > unset LD_LIBRARY_PATH and try re-emerging glibc
>> 
>> of course that's what i did, i was just suggesting that the ebuild
>> could do this for you...
>
> Why should it if the ./configure script handles it nicely ? =)

Huh?

As I understand it, the process went like this:

    $ emerge glibc
    ==> failed

    $ unset LD_LIBRARY_PATH
    $ emerge glibc
    ==> succeeded

How is that the ./configure script handling it nicely?

Can't the glibc ebuild just unset LD_LIBRARY_PATH at the same time that
it unsets LANGUAGE, LANG, and LC_ALL?


--
gentoo-dev@gentoo.org mailing list