Configure does not find libs in /lib/x86_64-linux-gnu

Bug #739693 reported by TundraMan on 2011-03-21
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
perl5
Unknown
Unknown
perl (Debian)
Fix Released
Unknown
perl (Ubuntu)
High
Steve Langasek
Natty
High
Steve Langasek

Bug Description

Binary package hint: perl

Attempting to build the 'perl' package fails on natty.

libc6 in natty has moved the core system libs (such as libm) that used to be in /lib into /lib/x86_64-linux-gnu. Perl's Configure script does not include this path in libspath/libpth/loclibpth so it fails to find the libraries. Subsequently the libs are dropped from the build line for gcc and the build falls over during linking.

I have reproduced this on my system by grabbing the src-deb via 'apt-get source perl' both on the base system and in a pbuilder env..

The end result is a build failure
----

cc -fstack-protector -L/usr/local/lib -o miniperl \
              gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.
o deb.o universal.o xsutils.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o \
            miniperlmain.o opmini.o perlmini.o
util.o: In function `Perl_safesysmalloc':
/tmp/buildd/perl-5.10.1/util.c:78: undefined reference to `pthread_getspecific'
util.o: In function `Perl_safesysrealloc':
/tmp/buildd/perl-5.10.1/util.c:134: undefined reference to `pthread_getspecific'
util.o: In function `Perl_croak_nocontext':
/tmp/buildd/perl-5.10.1/util.c:1444: undefined reference to `pthread_getspecific'
util.o: In function `Perl_safesyscalloc':
/tmp/buildd/perl-5.10.1/util.c:271: undefined reference to `pthread_getspecific'
util.o: In function `Perl_die_nocontext':
...

---------
Under a normal build several libs should follow at the end of the build line, like '-lm'

Related branches

TundraMan (asselsm) wrote :
TundraMan (asselsm) wrote :

I am sure there are other suitable fixes and possible debate if this should be made a 'default' search path but here is a potential fix none the less.

I can look into this, unfortunately not today. There was a lot of work done
to get the correct 64-bit libs found on Linux since there didn't seem to be
a standard location for them across distributions. My guess is that Ubuntu
currently has found another way to make this happen or there is some other
configuration that has been done on the build machine that isn't on your
machine.

Steve

On Tue, Mar 22, 2011 at 10:56 AM, TundraMan <email address hidden>wrote:

> I am sure there are other suitable fixes and possible debate if this
> should be made a 'default' search path but here is a potential fix none
> the less.
>
> ** Patch added: "Add the new lib paths to default search paths used by
> Configure"
>
> https://bugs.launchpad.net/ubuntu/+source/perl/+bug/739693/+attachment/1930371/+files/configure-adjust-for-moving-libs.patch
>
> --
> You received this bug notification because you are subscribed to perl in
> Ubuntu.
> https://bugs.launchpad.net/bugs/739693
>
> Title:
> Configure does not find libs in /lib/x86_64-linux-gnu
>

On Mar 22, 2011 12:53pm, Steve Peters <email address hidden> wrote:
> I can look into this, unfortunately not today. There was a lot of work
> done
> to get the correct 64-bit libs found on Linux since there didn't seem to
> be
> a standard location for them across distributions. My guess is that Ubuntu
> currently has found another way to make this happen or there is some other
> configuration that has been done on the build machine that isn't on your
> machine.

> Steve

Thanks Steve. I am in no rush, I just noticed this issue when building perl
on its own. I decided to see if Ubu had a fix for the package, figuring it
would have been hit already by someone, I didn't see anything, so raised
the defect. I thought it might just be my system but using pbuilder should
have created a fresh chroot env. ensuring no pollution from my system.

Mark

> On Tue, Mar 22, 2011 at 10:56 AM, TundraMan

> <email address hidden>>wrote:

> > I am sure there are other suitable fixes and possible debate if this

> > should be made a 'default' search path but here is a potential fix none

> > the less.

> >

> > ** Patch added: "Add the new lib paths to default search paths used by

> > Configure"

> >

> >
> https://bugs.launchpad.net/ubuntu/+source/perl/+bug/739693/+attachment/1930371/+files/configure-adjust-for-moving-libs.patch

> >

> > --

> > You received this bug notification because you are subscribed to perl in

> > Ubuntu.

> > https://bugs.launchpad.net/bugs/739693

> >

> >> Title:

> > Configure does not find libs in /lib/x86_64-linux-gnu

> >

> --

> You received this bug notification because you are a direct subscriber

> of the bug.

> https://bugs.launchpad.net/bugs/739693

> Title:

> Configure does not find libs in /lib/x86_64-linux-gnu

> To unsubscribe from this bug, go to:

> https://bugs.launchpad.net/ubuntu/+source/perl/+bug/739693/+subscribe

tags: added: patch
Matthias Klose (doko) wrote :

seen in a test rebuild too. are these changes enough to fix the buil failures of various perl modules too?

http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20110329-natty.html

Changed in perl (Ubuntu):
assignee: nobody → Steve Langasek (vorlon)
importance: Undecided → High
milestone: none → ubuntu-11.04-beta-2
status: New → Triaged
tags: added: ftbfs natty
Andy Dougherty (doughera) wrote :

This issue is being tracked upstream as

    http://rt.perl.org/rt3/Ticket/Display.html?id=86854

I'd like to fix this upstream, but need some basic information first.

Assuming this is a deliberate change in Ubuntu, the fix for perl-5.14 will be
to detect this situation in the hints/linux.sh hint file and add the
appropriate plibpth values automatically. In order to do that, I could
use some help:

First: How does one reliably detect this version of Ubuntu? (Assume I have never used Ubuntu, and don't have access to it for testing.)

Second: Does anyone understand this new organization enough to suggest how to coax
the necessary directory name (e.g. /lib/i386-linux-gnu) out of the build
tools? (For example, what should it be on an amd64 system? How about
PPC? SPARC? Are there trailing 32s or 64s on any of those names? etc.)

Thank you.

    Andy Dougherty <email address hidden>

On Mar 30, 2011 3:51pm, Andy Dougherty <email address hidden> wrote:
> This issue is being tracked upstream as

> http://rt.perl.org/rt3/Ticket/Display.html?id=86854

> I'd like to fix this upstream, but need some basic information first.

> Assuming this is a deliberate change in Ubuntu, the fix for perl-5.14
> will be

> to detect this situation in the hints/linux.sh hint file and add the

> appropriate plibpth values automatically. In order to do that, I could

> use some help:

> First: How does one reliably detect this version of Ubuntu? (Assume I

look in '/etc/issue' should be good.

> have never used Ubuntu, and don't have access to it for testing.)

I often install OSs in VMs now to get over this, if you care to see things
first hand.

Mark

> Second: Does anyone understand this new organization enough to suggest
> how to coax

> the necessary directory name (eg /lib/i386-linux-gnu) out of the build

> tools? (For example, what should it be on an amd64 system? How about

> PPC? SPARC? Are there trailing 32s or 64s on any of those names? etc.)

> Thank you.

> Andy Dougherty <email address hidden>

> ** Bug watch added: rt.perl.org/rt3/ #86854

> http://rt.perl.org/rt3/Ticket/Display.html?id=86854

> --

> You received this bug notification because you are a direct subscriber

> of the bug.

> https://bugs.launchpad.net/bugs/739693

> Title:

> Configure does not find libs in /lib/x86_64-linux-gnu

> To unsubscribe from this bug, go to:

> https://bugs.launchpad.net/ubuntu/+source/perl/+bug/739693/+subscribe

Steve Langasek (vorlon) wrote :

Hi Andy,

On Wed, Mar 30, 2011 at 07:51:36PM -0000, Andy Dougherty wrote:
> Assuming this is a deliberate change in Ubuntu,

Yes, this is a deliberate change. Sorry that this is causing trouble for
building perl, it seems that there are a few more build systems out there
bypassing the compiler's view of the available libraries than we had
anticipated.

> Second: Does anyone understand this new organization enough to suggest how to coax
> the necessary directory name (e.g. /lib/i386-linux-gnu) out of the build
> tools? (For example, what should it be on an amd64 system? How about
> PPC? SPARC? Are there trailing 32s or 64s on any of those names? etc.)

To find the directory name, there are two options that can be used reliably
without having to embed detailed logic into perl's build system. The first
is preferable, since it doesn't rely on Ubuntu-specific interfaces at all.
The major downside is that it assumes use of gcc or something supporting
similar commandline options - gcc is the standard compiler on Debian and
Ubuntu today, but there are of course other compilers available and someone
might use one of these for building perl on Ubuntu.

$ ${CC:-gcc} -print-search-dirs | grep libraries |cut -f2- -d= | \
  sed -e's/\:/\n/g' | xargs -n1 readlink -f | uniq
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5
/usr/x86_64-linux-gnu/lib
/usr/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu/4.5.2
/lib
/usr/lib/x86_64-linux-gnu/4.5.2
/usr/lib
/usr/lib/x86_64-linux-gnu
$

this spits out the full list of libraries that gcc is configured to look in;
I think it would be appropriate to prepend this to the search path. Maybe
filtering out directories with 'gcc' in the name or that have a final path
component consisting of [0-9.]+ is also wanted.

The other option is to check the output of dpkg-architecture
-qDEB_HOST_MULTIARCH; but this relies on the dpkg-dev package which is not
guaranteed to be installed when building perl (at least, not when building
from upstream source).

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

tags: added: multiarch
removed: patch
Steve Langasek (vorlon) wrote :

(BTW, since we have every intention of proposing multiarch as a cross-distribution extension to the FHS, at some point we will hopefully have a standalone tool other than dpkg-architecture that can be queried for the correct paths; but we're not there yet.)

Andy Dougherty (doughera) wrote :

>> First: How does one reliably detect this version of Ubuntu? (Assume I
>> have never used Ubuntu, and don't have access to it for testing.)

>look in '/etc/issue' should be good.

What, precisely, do I look for? I want to write a shell test to add in these extra
paths on this version (and future versions) of Ubuntu, but not add in these
extra paths otherwise.

Steve Langasek (vorlon) wrote :

>>> First: How does one reliably detect this version of Ubuntu? (Assume I
>>> have never used Ubuntu, and don't have access to it for testing.)

>>look in '/etc/issue' should be good.

> What, precisely, do I look for? I want to write a shell test to add in these extra
> paths on this version (and future versions) of Ubuntu, but not add in these
> extra paths otherwise.

I would specifically advise against checking the platform, and instead do something vendor-neutral like the gcc -print-search-dirs check above. That way anything you implement will also work for other vendors who adopt multiarch.

If you *must* check the platform, $(lsb_release -is) is a better check, but lsb_release is not included by default on Debian systems and this issue is going to turn up on Debian too soon enough.

Andy Dougherty (doughera) wrote :

> If you *must* check the platform, $(lsb_release -is) is a better check, but lsb_release is not included by default on Debian
> systems and this issue is going to turn up on Debian too soon enough.

But what would the output of "lsb_release -is" be?

I do appreciate your warning that Debian will go the same way as well.

I also fully understand that checking the platform may not turn out to be the wisest course of action. However, perl 5 is in code freeze preparing for the 5.14.0 release, so I am trying to find as minimally invasive a fix as possible. I don't know what testing on other Linux distributions will turn up, but I do know that on Ubuntu 11.04, at least, I need to incorporate this fix, so I would like to be able to tell what platform I'm on.

Thank you for your prompt help.

Steve Langasek (vorlon) wrote :

On Thu, Mar 31, 2011 at 01:26:05AM -0000, Andy Dougherty wrote:
> > If you *must* check the platform, $(lsb_release -is) is a better check, but lsb_release is not included by default on Debian
> > systems and this issue is going to turn up on Debian too soon enough.

> But what would the output of "lsb_release -is" be?

This outputs 'Ubuntu'. Sorry, I should've said.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
<email address hidden> <email address hidden>

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package perl - 5.10.1-17ubuntu4

---------------
perl (5.10.1-17ubuntu4) natty; urgency=low

  * debian/config.debian: pass multiarch paths to the build (if
    available) so that we're able to find libraries needed to build.
    LP: #739693.
 -- Steve Langasek <email address hidden> Wed, 30 Mar 2011 13:44:06 -0700

Changed in perl (Ubuntu Natty):
status: Triaged → Fix Released
Changed in perl (Debian):
status: Unknown → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.