Mailing List Archive: Perl: porters

Multiarch support from Debian breaks all my old perls

Index | Next | Previous | View Threaded

andreas.koenig.7os6VVqR at franz

May 1, 2012, 1:03 AM

Post #1 of 11 (182 views)
Permalink

Multiarch support from Debian breaks all my old perls

I have observed it on Debian sid and have not looked at other OSes. I
used to build my perls with gcc 4.4.5 and since Debian upgraded to gcc
4.6.3 and multiarch I encounter dynamic loading problems.

The pattern is that a perl program tries to use dynamic loading to load
a system "so" library but does not find it anymore. This happens because
meanwhile some system update has put the library into directories like
/lib/x86_64-linux-gnu/ or /usr/lib/x86_64-linux-gnu/ or so. The old perl
does not know about and does not look into the new-fangled directories
and the dynamic loading fails.

The old perl that was built before multiarch support had something like
this:

% .../bin/perl -V:libpth
libpth='/usr/local/lib /lib/../lib /usr/lib/../lib /lib /usr/lib /lib64 /usr/lib64';

The perls I build now with gcc 4.6.3 have:

% .../bin/perl -V:libpth
libpth='/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib';

The only workaround I found so far is to edit the Config.pm of the old
perl and add the new installation directories there. This works
remarkably well but I'm not sure about details like best ordering.

I wonder if somebody has other solutions short of removing all old perls
from my disk and recompiling everything?

--
andreas

tony at develop-help

May 1, 2012, 2:25 AM

Post #2 of 11 (186 views)
Permalink

Re: Multiarch support from Debian breaks all my old perls [In reply to]

On Tue, May 01, 2012 at 10:03:58AM +0200, Andreas J. Koenig wrote:
> I have observed it on Debian sid and have not looked at other OSes. I
> used to build my perls with gcc 4.4.5 and since Debian upgraded to gcc
> 4.6.3 and multiarch I encounter dynamic loading problems.
>
> The pattern is that a perl program tries to use dynamic loading to load
> a system "so" library but does not find it anymore. This happens because
> meanwhile some system update has put the library into directories like
> /lib/x86_64-linux-gnu/ or /usr/lib/x86_64-linux-gnu/ or so. The old perl
> does not know about and does not look into the new-fangled directories
> and the dynamic loading fails.
>
> The old perl that was built before multiarch support had something like
> this:
>
> % .../bin/perl -V:libpth
> libpth='/usr/local/lib /lib/../lib /usr/lib/../lib /lib /usr/lib /lib64 /usr/lib64';
>
> The perls I build now with gcc 4.6.3 have:
>
> % .../bin/perl -V:libpth
> libpth='/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib';

From reproducing this for Imager, the problem isn't gcc, which returns
the full set of directories even in stable:

tony [at] mar:~$ gcc --version
gcc (Debian 4.4.5-8) 4.4.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

tony [at] mar:~$ gcc -print-search-dirs | grep libraries
libraries: =/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../x86_64-linux-gnu/lib/x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../x86_64-linux-gnu/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../x86_64-linux-gnu/4.4.5/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../lib/:/lib/x86_64-linux-gnu/4.4.5/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/4.4.5/:/usr/lib/../lib/:/usr/lib/x86_64-linux-gnu/x86_64-linux-gnu/4.4.5/:/usr/lib/x86_64-linux-gnu/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../../x86_64-linux-gnu/lib/:/usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../:/lib/:/usr/lib/:/usr/lib/x86_64-linux-gnu/

Possibly this could be considered a bug from Configure stripping
directories that don't exist, after all, they may exist later.

> The only workaround I found so far is to edit the Config.pm of the old
> perl and add the new installation directories there. This works
> remarkably well but I'm not sure about details like best ordering.
>
> I wonder if somebody has other solutions short of removing all old perls
> from my disk and recompiling everything?

I don't see a solution beyond rebuilding or mangling Config.pm.

Tony

nick at ccl4

May 1, 2012, 2:27 AM

Post #3 of 11 (176 views)
Permalink

Re: Multiarch support from Debian breaks all my old perls [In reply to]

On Tue, May 01, 2012 at 07:25:18PM +1000, Tony Cook wrote:
> On Tue, May 01, 2012 at 10:03:58AM +0200, Andreas J. Koenig wrote:

> > The only workaround I found so far is to edit the Config.pm of the old
> > perl and add the new installation directories there. This works
> > remarkably well but I'm not sure about details like best ordering.
> >
> > I wonder if somebody has other solutions short of removing all old perls
> > from my disk and recompiling everything?
>
> I don't see a solution beyond rebuilding or mangling Config.pm.

But possibly the "best" way, to get the ordering "right", is to run blead's
Configure, and then transplant the values it generates into the existing
Config.pm

Nicholas Clark

Tom.Horsley at ccur

May 1, 2012, 3:18 AM

Post #4 of 11 (176 views)
Permalink

RE: Multiarch support from Debian breaks all my old perls [In reply to]

> But possibly the "best" way, to get the ordering "right", is to run blead's
> Configure, and then transplant the values it generates into the existing
> Config.pm

Wouldn't the best way to be stop trying to remember things that might
change when gcc changes and just ask it again?

nick at ccl4

May 1, 2012, 3:32 AM

Post #5 of 11 (173 views)
Permalink

Re: Multiarch support from Debian breaks all my old perls [In reply to]

On Tue, May 01, 2012 at 06:18:25AM -0400, Horsley, Tom wrote:
> > But possibly the "best" way, to get the ordering "right", is to run blead's
> > Configure, and then transplant the values it generates into the existing
> > Config.pm
>
> Wouldn't the best way to be stop trying to remember things that might
> change when gcc changes and just ask it again?

Sure, but in context I meant "the best way for Andreas to get out of the
difficulties he finds himself"

From an implementation point of view, "just ask it again" likely would
involve duplicating a fair chunk of Configure as Perl code to run at
module build time, for a relatively rare case.

gcc certainly didn't use to bother with the equivalent of this level of
defensiveness - it sucks in system headers files privately, and if you
upgrade your OS you're supposed to rebuild gcc.

Nicholas Clark

andreas.koenig.7os6VVqR at franz

May 7, 2012, 11:34 PM

Post #6 of 11 (146 views)
Permalink

Re: Multiarch support from Debian breaks all my old perls [In reply to]

>>>>> On Tue, 1 May 2012 10:27:47 +0100, Nicholas Clark <nick [at] ccl4> said:

> On Tue, May 01, 2012 at 07:25:18PM +1000, Tony Cook wrote:
>> On Tue, May 01, 2012 at 10:03:58AM +0200, Andreas J. Koenig wrote:

>> > The only workaround I found so far is to edit the Config.pm of the old
>> > perl and add the new installation directories there. This works
>> > remarkably well but I'm not sure about details like best ordering.
>> >
>> > I wonder if somebody has other solutions short of removing all old perls
>> > from my disk and recompiling everything?
>>
>> I don't see a solution beyond rebuilding or mangling Config.pm.

> But possibly the "best" way, to get the ordering "right", is to run blead's
> Configure, and then transplant the values it generates into the existing
> Config.pm

Thanks a lot for your support. In the meantime I've tweaked all
Config.pm files of all my smokers and have not yet seen any adverse
effect.

Learning from this incident: should we file a ticket against configure
that it should never drop non-existant directories from libpth?

--
andreas

tony at develop-help

May 8, 2012, 9:05 PM

Post #7 of 11 (142 views)
Permalink

Re: Multiarch support from Debian breaks all my old perls [In reply to]

On Tue, May 08, 2012 at 08:34:01AM +0200, Andreas J. Koenig wrote:
> >>>>> On Tue, 1 May 2012 10:27:47 +0100, Nicholas Clark <nick [at] ccl4> said:
>
> > On Tue, May 01, 2012 at 07:25:18PM +1000, Tony Cook wrote:
> >> On Tue, May 01, 2012 at 10:03:58AM +0200, Andreas J. Koenig wrote:
>
> >> > The only workaround I found so far is to edit the Config.pm of the old
> >> > perl and add the new installation directories there. This works
> >> > remarkably well but I'm not sure about details like best ordering.
> >> >
> >> > I wonder if somebody has other solutions short of removing all old perls
> >> > from my disk and recompiling everything?
> >>
> >> I don't see a solution beyond rebuilding or mangling Config.pm.
>
> > But possibly the "best" way, to get the ordering "right", is to run blead's
> > Configure, and then transplant the values it generates into the existing
> > Config.pm
>
> Thanks a lot for your support. In the meantime I've tweaked all
> Config.pm files of all my smokers and have not yet seen any adverse
> effect.
>
> Learning from this incident: should we file a ticket against configure
> that it should never drop non-existant directories from libpth?

I'm inclined to do so, but then this issue, but then this issue bit me*

Tony

* which I could have ignored if I wasn't so manic about getting Imager
to build anywhere it can

ikegami at adaelis

May 8, 2012, 9:37 PM

Post #8 of 11 (143 views)
Permalink

Re: Multiarch support from Debian breaks all my old perls [In reply to]

On Tue, May 1, 2012 at 4:03 AM, Andreas J. Koenig <
andreas.koenig.7os6VVqR [at] franz> wrote:

> The only workaround I found so far is to edit the Config.pm of the old
> perl and add the new installation directories there. This works
> remarkably well but I'm not sure about details like best ordering.
>

Someone on StackOverflow is suffering from what appears to be the same
problem.
http://stackoverflow.com/questions/10506314/perl-on-debian-confliciting-perl-installations-on-a-system

- Eric

tony at develop-help

May 8, 2012, 9:51 PM

Post #9 of 11 (143 views)
Permalink

Re: Multiarch support from Debian breaks all my old perls [In reply to]

On Wed, May 09, 2012 at 12:37:23AM -0400, Eric Brine wrote:
> On Tue, May 1, 2012 at 4:03 AM, Andreas J. Koenig <
> andreas.koenig.7os6VVqR [at] franz> wrote:
>
> > The only workaround I found so far is to edit the Config.pm of the old
> > perl and add the new installation directories there. This works
> > remarkably well but I'm not sure about details like best ordering.
> >
>
> Someone on StackOverflow is suffering from what appears to be the same
> problem.
> http://stackoverflow.com/questions/10506314/perl-on-debian-confliciting-perl-installations-on-a-system

That looks like a different problem.

The problem here is that libpth isn't populated with say
/usr/lib/x86_64-linux-gnu/ despite the probe in hints/linux.sh picking it up.

Since the system does search that directory checking for the library
with Devel::CheckLib will pass, but EU::MM* will strip the library
entry from LIBS, breaking the build of the library.

At least that's the problem as I'd experienced it.

Tony

* I don't know what M::B does

rabbit-p5p at rabbit

May 9, 2012, 11:46 PM

Post #10 of 11 (141 views)
Permalink

Re: Multiarch support from Debian breaks all my old perls [In reply to]

Andreas J. Koenig wrote:
>>>>>> On Tue, 1 May 2012 10:27:47 +0100, Nicholas Clark <nick [at] ccl4> said:
>
> > On Tue, May 01, 2012 at 07:25:18PM +1000, Tony Cook wrote:
> >> On Tue, May 01, 2012 at 10:03:58AM +0200, Andreas J. Koenig wrote:
>
> >> > The only workaround I found so far is to edit the Config.pm of the old
> >> > perl and add the new installation directories there. This works
> >> > remarkably well but I'm not sure about details like best ordering.
> >> >
> >> > I wonder if somebody has other solutions short of removing all old perls
> >> > from my disk and recompiling everything?
> >>
> >> I don't see a solution beyond rebuilding or mangling Config.pm.
>
> > But possibly the "best" way, to get the ordering "right", is to run blead's
> > Configure, and then transplant the values it generates into the existing
> > Config.pm
>
> Thanks a lot for your support. In the meantime I've tweaked all
> Config.pm files of all my smokers and have not yet seen any adverse
> effect.

I think you missed some:
http://matrix.cpantesters.org/?dist=SQL-Translator%200.11011;reports=1;os=linux

Cheers

andreas.koenig.7os6VVqR at franz

May 10, 2012, 6:41 PM

Post #11 of 11 (144 views)
Permalink

Re: Multiarch support from Debian breaks all my old perls [In reply to]

>>>>> On Thu, 10 May 2012 08:46:30 +0200, Peter Rabbitson <rabbit-p5p [at] rabbit> said:

>> Thanks a lot for your support. In the meantime I've tweaked all
>> Config.pm files of all my smokers and have not yet seen any adverse
>> effect.

> I think you missed some:
> http://matrix.cpantesters.org/?dist=SQL-Translator%200.11011;reports=1;os=linux

This is different. On my debian I cannot install both libjpeg62-dev and
libjpeg8-dev, they conflict. An upgrade to libjpeg8 broke all old GD
installations.

Hmm. In this case I think I'll have to remove all my old smokers and
recreate them from scratch. Will do asap. I'm sorry for ruining your
FAIL/PASS ratio:(

--
andreas

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads