[gentoo-user] libtool problem

[gentoo-user] libtool problem

[Helmut Jarausch]

Hi,

since a short time many (not all) packages fail to build with a message
like
/bin/sed: can't read /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgomp.la

The problem is that I have upgraded to gcc-4.3.3 so there is no path
/usr/lib/gcc/i686-pc-linux-gnu/4.3.2
anymore.

I have rebuilt libtool, sourced /etc/profile
still I cannot get rid of this problem.

Has anybody an idea where this comes from and how to fix this?

Many thanks for hint,
Helmut.

-- 
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

Re: [gentoo-user] libtool problem

[Dirk Heinrichs]

[-- Attachment #1: Type: text/plain, Size: 488 bytes --]

Am Dienstag, 3. Februar 2009 13:15:55 schrieb Helmut Jarausch:

> since a short time many (not all) packages fail to build with a message
> like
> /bin/sed: can't read /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgomp.la
>
> The problem is that I have upgraded to gcc-4.3.3 so there is no path
> /usr/lib/gcc/i686-pc-linux-gnu/4.3.2
> anymore.
>
> I have rebuilt libtool, sourced /etc/profile
> still I cannot get rid of this problem.

Did you run "fix_libtool_files.sh 4.3.2"?

HTH...

	Dirk

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

Re: [gentoo-user] libtool problem

[Helmut Jarausch]

On  3 Feb, Dirk Heinrichs wrote:
> Am Dienstag, 3. Februar 2009 13:15:55 schrieb Helmut Jarausch:
> 
>> since a short time many (not all) packages fail to build with a message
>> like
>> /bin/sed: can't read /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgomp.la
>>
>> The problem is that I have upgraded to gcc-4.3.3 so there is no path
>> /usr/lib/gcc/i686-pc-linux-gnu/4.3.2
>> anymore.
>>
>> I have rebuilt libtool, sourced /etc/profile
>> still I cannot get rid of this problem.
> 
> Did you run "fix_libtool_files.sh 4.3.2"?
> 

Thanks!
Where does this beast come from?
Helmut.


-- 
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

Re: [gentoo-user] libtool problem

[Justin]

[-- Attachment #1: Type: text/plain, Size: 685 bytes --]

Helmut Jarausch schrieb:
> On  3 Feb, Dirk Heinrichs wrote:
>> Am Dienstag, 3. Februar 2009 13:15:55 schrieb Helmut Jarausch:
>>
>>> since a short time many (not all) packages fail to build with a message
>>> like
>>> /bin/sed: can't read /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgomp.la
>>>
>>> The problem is that I have upgraded to gcc-4.3.3 so there is no path
>>> /usr/lib/gcc/i686-pc-linux-gnu/4.3.2
>>> anymore.
>>>
>>> I have rebuilt libtool, sourced /etc/profile
>>> still I cannot get rid of this problem.
>> Did you run "fix_libtool_files.sh 4.3.2"?
>>
> 
> Thanks!
> Where does this beast come from?
> Helmut.
> 
> 

Do you read the elog messages?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-user] Re: libtool problem

[Nikos Chantziaras]

Helmut Jarausch wrote:
> On  3 Feb, Dirk Heinrichs wrote:
>> Am Dienstag, 3. Februar 2009 13:15:55 schrieb Helmut Jarausch:
>>
>>> since a short time many (not all) packages fail to build with a message
>>> like
>>> /bin/sed: can't read /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgomp.la
>>>
>>> The problem is that I have upgraded to gcc-4.3.3 so there is no path
>>> /usr/lib/gcc/i686-pc-linux-gnu/4.3.2
>>> anymore.
>>>
>>> I have rebuilt libtool, sourced /etc/profile
>>> still I cannot get rid of this problem.
>> Did you run "fix_libtool_files.sh 4.3.2"?
>>
> 
> Thanks!
> Where does this beast come from?

It's also in the official documentation.  Chapter "Gentoo GCC Upgrade 
Guide", section "Frequent Error Messages" :P

http://www.gentoo.org/doc/en/gcc-upgrading.xml#doc_chap5

Re: [gentoo-user] libtool problem

[Volker Armin Hemmann]

On Dienstag 03 Februar 2009, Helmut Jarausch wrote:
> Hi,
>
> since a short time many (not all) packages fail to build with a message
> like
> /bin/sed: can't read /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgomp.la
>
> The problem is that I have upgraded to gcc-4.3.3 so there is no path
> /usr/lib/gcc/i686-pc-linux-gnu/4.3.2
> anymore.
>
> I have rebuilt libtool, sourced /etc/profile
> still I cannot get rid of this problem.
>
> Has anybody an idea where this comes from and how to fix this?
>
> Many thanks for hint,
> Helmut.

if you would have looked here:
http://www.gentoo.org/

you would have seen this:
  gcc-4.3.3 and broken libtool archives
linking to:
http://psykil.livejournal.com/334483.html

Re: [gentoo-user] libtool problem

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 495 bytes --]

On Tue, 03 Feb 2009 13:15:55 +0100 (CET), Helmut Jarausch wrote:

> since a short time many (not all) packages fail to build with a message
> like
> /bin/sed: can't read /usr/lib/gcc/i686-pc-linux-gnu/4.3.2/libgomp.la
> 
> The problem is that I have upgraded to gcc-4.3.3 so there is no path
> /usr/lib/gcc/i686-pc-linux-gnu/4.3.2
> anymore.

Re-emerge gcc-4.3.3 - this was fixed without a revision bump.


-- 
Neil Bothwick

A man needs a mistress - just to break the monogamy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] libtool problem

[Helmut Jarausch]

On  3 Feb, Neil Bothwick wrote:

> Re-emerge gcc-4.3.3 - this was fixed without a revision bump.
                                       ^^^^^^^^^^^^^^^^^^^^^^^

I do love this !!!

Many thanks,
Helmut.


-- 
Helmut Jarausch

Lehrstuhl fuer Numerische Mathematik
RWTH - Aachen University
D 52056 Aachen, Germany

Re: [gentoo-user] libtool problem

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

On Tue, 03 Feb 2009 16:03:00 +0100 (CET)
Helmut Jarausch <jarausch@igpm.rwth-aachen.de> wrote:

> I do love this !!!

And I hate to re-emerge same gcc every time some minor bug (which I
didn't happen to reproduce) is fixed.

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] libtool problem

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

On Tue, 3 Feb 2009 20:23:17 +0500, Mike Kazantsev wrote:

> And I hate to re-emerge same gcc every time some minor bug (which I
> didn't happen to reproduce) is fixed.

IKWYM but I think, on balance, this one would have benefited from a bump
as the effects of the breakage were quite widespread. It did make a
difference to the installed files, which is the usual criterion for a
bump.


-- 
Neil Bothwick

THE BORG: Calm, Cool and Collective...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-user] Re: libtool problem

[ABCD]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Bothwick wrote:
> Mike Kazantsev wrote:
> 
>> And I hate to re-emerge same gcc every time some minor bug (which I
>> didn't happen to reproduce) is fixed.
> 
> IKWYM but I think, on balance, this one would have benefited from a bump
> as the effects of the breakage were quite widespread. It did make a
> difference to the installed files, which is the usual criterion for a
> bump.

The reason there wasn't a bump (IIRC) was that the ebuild never changed
- - only the eclass did.  If you emerged any version of GCC during the
window where the eclass was broken, that version of GCC would have been
broken.

- --
ABCD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmJCq4ACgkQOypDUo0oQOqeqwCgrFG9t4t3+ZmTKY5EcjW81Ab/
YIoAmQEQh7FXNlrIj/dCmqSGoIk+g4YG
=3Eiv
-----END PGP SIGNATURE-----

Re: [gentoo-user] Re: libtool problem

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

On Tue, 03 Feb 2009 22:25:34 -0500, ABCD wrote:

> The reason there wasn't a bump (IIRC) was that the ebuild never changed
> - - only the eclass did.  If you emerged any version of GCC during the
> window where the eclass was broken, that version of GCC would have been
> broken.

Of course, I'd forgotten that the change was in the eclass.


-- 
Neil Bothwick

I understand the answers, the questions throw me.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [gentoo-user] Re: libtool problem

[Dirk Heinrichs]

[-- Attachment #1: Type: text/plain, Size: 475 bytes --]

Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD:

> The reason there wasn't a bump (IIRC) was that the ebuild never changed
> - only the eclass did.  If you emerged any version of GCC during the
> window where the eclass was broken, that version of GCC would have been
> broken.

That also means that portage is broken. Whenever something changes where other 
things depend on, those other things should be rebuilt. This doesn't happen 
here.

Bye...

	Dirk

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

Re: [gentoo-user] Re: libtool problem

[Alan McKinnon]

On Wednesday 04 February 2009 20:17:33 Dirk Heinrichs wrote:
> Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD:
> > The reason there wasn't a bump (IIRC) was that the ebuild never changed
> > - only the eclass did.  If you emerged any version of GCC during the
> > window where the eclass was broken, that version of GCC would have been
> > broken.
>
> That also means that portage is broken. Whenever something changes where
> other things depend on, those other things should be rebuilt. This doesn't
> happen here.

I disagree, that would cause many more spurious rebuilds than is needed if it 
were automated. Portage cannot tell how important or how deep a change is, 
that requires a human to look and see. So what is needed is a flag that 
portage recognizes as an instruction to do a revdep-rebuild-style search and 
find everything using a specific changed file, and rebuild those. The flag is 
set under dev control.

Blindly doing what you suggest leads to this:

appA depends on libB. 
libB has a bug which is fixed but no changes to the API or ABI occur, so appA 
does not need to be rebuilt, it simply uses the new compiled lib when run.
This circumstance will likely happen many many times more often that the 
updated eclass that is the subject of this thread.

Therefore, a simple elog entry is a valid handling and fully compliant with 
the principle of The Simplest Thing That Could Possibly Work.

-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] Re: libtool problem

[Dirk Heinrichs]

[-- Attachment #1: Type: text/plain, Size: 1698 bytes --]

Am Mittwoch, 4. Februar 2009 21:21:38 schrieb Alan McKinnon:
> On Wednesday 04 February 2009 20:17:33 Dirk Heinrichs wrote:
> > Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD:
> > > The reason there wasn't a bump (IIRC) was that the ebuild never changed
> > > - only the eclass did.  If you emerged any version of GCC during the
> > > window where the eclass was broken, that version of GCC would have been
> > > broken.
> >
> > That also means that portage is broken. Whenever something changes where
> > other things depend on, those other things should be rebuilt. This
> > doesn't happen here.
>
> I disagree, that would cause many more spurious rebuilds than is needed if
> it were automated.

Why spurious? The package manager should be smart enough to tell the user: 
"Rebuild because of eclass change". Nothing spurious.

> Portage cannot tell how important or how deep a change
> is, that requires a human to look and see. So what is needed is a flag that
> portage recognizes as an instruction to do a revdep-rebuild-style search
> and find everything using a specific changed file, and rebuild those. The
> flag is set under dev control.

Not dev, user. Something equivalent to --newuse.

> Blindly doing what you suggest leads to this:
>
> appA depends on libB.

No. Sorry if this was misleading. I was only referring to dependencies between 
ebuilds and eclasses.

Library interdependencies are handled just fine by portage/revdep-rebuild.

> Therefore, a simple elog entry is a valid handling and fully compliant with
> the principle of The Simplest Thing That Could Possibly Work.

Elog entries are overlooked too often.

Bye...

	Dirk

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

Re: [gentoo-user] Re: libtool problem

[Alan McKinnon]

On Wednesday 04 February 2009 22:40:26 Dirk Heinrichs wrote:
> Am Mittwoch, 4. Februar 2009 21:21:38 schrieb Alan McKinnon:
> > On Wednesday 04 February 2009 20:17:33 Dirk Heinrichs wrote:
> > > Am Mittwoch, 4. Februar 2009 04:25:34 schrieb ABCD:
> > > > The reason there wasn't a bump (IIRC) was that the ebuild never
> > > > changed - only the eclass did.  If you emerged any version of GCC
> > > > during the window where the eclass was broken, that version of GCC
> > > > would have been broken.
> > >
> > > That also means that portage is broken. Whenever something changes
> > > where other things depend on, those other things should be rebuilt.
> > > This doesn't happen here.
> >
> > I disagree, that would cause many more spurious rebuilds than is needed
> > if it were automated.
>
> Why spurious? The package manager should be smart enough to tell the user:
> "Rebuild because of eclass change". Nothing spurious.

Portage only knows that the eclass changed. It does not know what the result 
of that change will be. Therefore it is not in a position to mandate that a 
rebuild of other apps is *required* in order to function correctly. Which 
leaves us with two options:

Tell the user to look and decide for themselves, or
Rebuild everything using the eclass anyway

The latter option will always fix problems but at a huge cost of most often 
rebuilding something that looks like it needs rebuilding but actually 
doesn't. Therefore spurious.

> > Portage cannot tell how important or how deep a change
> > is, that requires a human to look and see. So what is needed is a flag
> > that portage recognizes as an instruction to do a revdep-rebuild-style
> > search and find everything using a specific changed file, and rebuild
> > those. The flag is set under dev control.
>
> Not dev, user. Something equivalent to --newuse.

I was thinking more along the lines of what @preserved-rebuild does. Some 
mechanism in the ebuild that includes a package in a list of stuff to be 
rebuilt. Obviously this is something new and a fairly deep change to portage 
so I can't think of a decent parallel or analogy.

> > Blindly doing what you suggest leads to this:
> >
> > appA depends on libB.
>
> No. Sorry if this was misleading. I was only referring to dependencies
> between ebuilds and eclasses.

OK

> Library interdependencies are handled just fine by portage/revdep-rebuild.
>
> > Therefore, a simple elog entry is a valid handling and fully compliant
> > with the principle of The Simplest Thing That Could Possibly Work.
>
> Elog entries are overlooked too often.

True, but do we have anything better? As in a proven mechanism successfully 
used elsewhere to deal with comparable situations?



-- 
alan dot mckinnon at gmail dot com