Mailing List Archive

dlopen() NOT found
P5Pers,

Please excuse me if this is the wrong forum in which to inquire about
a build issue. If there's some other list to which I should direct
this inquiry, please let me know.

I had a hell of a time building Perl 5.8.8 on a 64 bit Red Hat
Enterprise Linux ES release 4 box today. First, during `make`, I got
these errors:

`sh cflags "optimize='-O2'" opmini.o` -DPERL_EXTERNAL_GLOB opmini.c
CCCMD = cc -DPERL_CORE -c -fno-strict-aliasing -pipe -
Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -O2 -Wall
cc -L/usr/local/lib -o miniperl \
miniperlmain.o opmini.o libperl.a
libperl.a(pp.o)(.text+0x272c): In function `Perl_pp_pow':
: undefined reference to `pow'
libperl.a(pp.o)(.text+0x346d): In function `Perl_pp_modulo':
: undefined reference to `floor'
libperl.a(pp.o)(.text+0x3495): In function `Perl_pp_modulo':
: undefined reference to `floor'
libperl.a(pp.o)(.text+0x355b): In function `Perl_pp_modulo':
: undefined reference to `fmod'
libperl.a(pp.o)(.text+0x7ce3): In function `Perl_pp_atan2':
: undefined reference to `atan2'
libperl.a(pp.o)(.text+0x7dc3): In function `Perl_pp_sin':
: undefined reference to `sin'
libperl.a(pp.o)(.text+0x7ee3): In function `Perl_pp_cos':
: undefined reference to `cos'
libperl.a(pp.o)(.text+0x8253): In function `Perl_pp_exp':
: undefined reference to `exp'
libperl.a(pp.o)(.text+0x83a5): In function `Perl_pp_log':
: undefined reference to `log'
libperl.a(pp.o)(.text+0x8577): In function `Perl_pp_sqrt':
: undefined reference to `sqrt'
libperl.a(pp.o)(.text+0x8728): In function `Perl_pp_int':
: undefined reference to `ceil'
libperl.a(pp.o)(.text+0x873e): In function `Perl_pp_int':
: undefined reference to `floor'
libperl.a(pp_pack.o)(.text+0x444c): In function `S_pack_rec':
: undefined reference to `floor'
libperl.a(pp_pack.o)(.text+0x4470): In function `S_pack_rec':
: undefined reference to `floor'
collect2: ld returned 1 exit status
make: *** [miniperl] Error 1

On #perl, jibsheet and q helped me figure out to change this line in
Makefile:

libs =

To:

libs = -lm

Then I was able to build and test Perl (only one failure, in lib/Net/
Ping/t/510_ping_udp.t, which I assume is because udp isn't on this
box). But then when I went to build Apache + mod_perl + mod_ssl, I
got some very strange errors:

gcc -DLINUX=22 -DHAVE_SET_DUMPABLE -DNO_DBM_REWRITEMAP -
DMOD_SSL=208127 -DMOD_PERL -DUSE_PERL_SSI -fno-strict-aliasing -pipe -
Wdeclaration-after-statement -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -DUSE_HSREGEX -DEAPI -DEAPI_MM -fPIC `./apaci`
-L/usr/local/src/openssl-0.9.8b -L./../../mm-1.4.0/.libs -rdynamic \
-o httpd buildmark.o modules.o modules/standard/libstandard.a
modules/ssl/libssl.a modules/perl/libperl.a main/libmain.a ./os/unix/
libos.a ap/libap.a regex/libregex.a -lm -lcrypt -lssl -lcrypto -
L/usr/local/lib /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/
DynaLoader/DynaLoader.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/
B/B.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/ByteLoader/
ByteLoader.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Cwd/Cwd.a /
usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Data/Dumper/Dumper.a /usr/
local/lib/perl5/5.8.8/x86_64-linux/auto/Devel/DProf/DProf.a /usr/
local/lib/perl5/5.8.8/x86_64-linux/auto/Devel/PPPort/PPPort.a /usr/
local/lib/perl5/5.8.8/x86_64-linux/auto/Devel/Peek/Peek.a /usr/local/
lib/perl5/5.8.8/x86_64-linux/auto/Digest/MD5/MD5.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/Encode/Encode.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/Encode/Byte/Byte.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/Encode/CN/CN.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/Encode/EBCDIC/EBCDIC.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/Encode/JP/JP.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/Encode/KR/KR.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/Encode/Symbol/Symbol.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/Encode/TW/TW.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/Encode/Unicode/Unicode.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/Fcntl/Fcntl.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/File/Glob/Glob.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/Filter/Util/Call/Call.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/I18N/Langinfo/Langinfo.a /usr/local/lib/
perl5/5.8.8/x86_64-linux/auto/IO/IO.a /usr/local/lib/perl5/5.8.8/
x86_64-linux/auto/IPC/SysV/SysV.a /usr/local/lib/perl5/5.8.8/x86_64-
linux/auto/List/Util/Util.a /usr/local/lib/perl5/5.8.8/x86_64-linux/
auto/MIME/Base64/Base64.a /usr/local/lib/perl5/5.8.8/x86_64-linux/
auto/Opcode/Opcode.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/
POSIX/POSIX.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/PerlIO/
encoding/encoding.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/
PerlIO/scalar/scalar.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/
PerlIO/via/via.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/
SDBM_File/SDBM_File.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/
Socket/Socket.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Storable/
Storable.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Sys/Hostname/
Hostname.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Sys/Syslog/
Syslog.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Time/HiRes/
HiRes.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/Unicode/
Normalize/Normalize.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/
attrs/attrs.a /usr/local/lib/perl5/5.8.8/x86_64-linux/auto/re/re.a /
usr/local/lib/perl5/5.8.8/x86_64-linux/auto/threads/threads.a /usr/
local/lib/perl5/5.8.8/x86_64-linux/auto/threads/shared/shared.a -L/
usr/local/lib/perl5/5.8.8/x86_64-linux/CORE -lperl -lm -lmm -ldl
/usr/local/lib/perl5/5.8.8/x86_64-linux/auto/SDBM_File/SDBM_File.a
(sdbm.o)(.rodata+0x0): multiple definition of `nullitem'
modules/ssl/libssl.a(ssl_util_sdbm.o)(.bss+0x0): first defined here
/usr/local/lib/perl5/5.8.8/x86_64-linux/auto/SDBM_File/SDBM_File.a
(sdbm.o)(.text+0x0): In function `sdbm_prep':
: multiple definition of `sdbm_prep'
...

I was surprised that there were so many seemingly irrelevant Perl
modules getting loaded, but through some investigation, I figured out
the problem. During `sh Configure -des`, I was getting:

<dld.h> NOT found.
dlopen() NOT found.

So it seems that Perl wasn't getting built to support the dynamic
loading of modules, so *all* of its C modules were compiled into it
statically. I had a 12MB perl. Yow!

Via some Googling and experimentation, I finally figured out to build
Perl with:

sh Configure -des -Dusedl

And then to enter ext/DynaLoader/dl_dlopen.xs" when prompted for
dynamic loading. Then I update Makefile with:

libs = -lnsl -ldl -lm -lcrypt -lutil -lc

Now I have a 1.2 MB perl, which seems much better. But I have a new
failing test:

lib/ExtUtils/t/Embed......................../libperl.a(pp.o)(.text
+0x272c): In function `Perl_pp_pow':
: undefined reference to `pow'
../libperl.a(pp.o)(.text+0x346d): In function `Perl_pp_modulo':
: undefined reference to `floor'
../libperl.a(pp.o)(.text+0x3495): In function `Perl_pp_modulo':
: undefined reference to `floor'
../libperl.a(pp.o)(.text+0x355b): In function `Perl_pp_modulo':
: undefined reference to `fmod'
../libperl.a(pp.o)(.text+0x7ce3): In function `Perl_pp_atan2':
: undefined reference to `atan2'
../libperl.a(pp.o)(.text+0x7dc3): In function `Perl_pp_sin':
: undefined reference to `sin'
../libperl.a(pp.o)(.text+0x7ee3): In function `Perl_pp_cos':
: undefined reference to `cos'
../libperl.a(pp.o)(.text+0x8253): In function `Perl_pp_exp':
: undefined reference to `exp'
../libperl.a(pp.o)(.text+0x83a5): In function `Perl_pp_log':
: undefined reference to `log'
../libperl.a(pp.o)(.text+0x8577): In function `Perl_pp_sqrt':
: undefined reference to `sqrt'
../libperl.a(pp.o)(.text+0x8728): In function `Perl_pp_int':
: undefined reference to `ceil'
../libperl.a(pp.o)(.text+0x873e): In function `Perl_pp_int':
: undefined reference to `floor'
../libperl.a(pp_pack.o)(.text+0x444c): In function `S_pack_rec':
: undefined reference to `floor'
../libperl.a(pp_pack.o)(.text+0x4470): In function `S_pack_rec':
: undefined reference to `floor'
collect2: ld returned 1 exit status
FAILED at test 1

It seems curious that I would get these errors again since I've added
-lm. But I can compile DBI and other C modules and they work again!

So my question is: do I need to worry about these test failures? And
what might be causing Configure not to be able to find dlopen() (it's
in /usr/include/dlfcn.h)? Could I be missing something else important?

I've never had a problem building Perl (except on Mac OS X 10.0 ages
ago) so I'm pretty surprised by this. Maybe something is wonky about
this box?

Many TIA,

David
Re: dlopen() NOT found [ In reply to ]
On 2006–06–08, at 04:43, David Wheeler wrote:
> So my question is: do I need to worry about these test failures?

Yes. The build's not doing what you want it to, so you should worry.

> And what might be causing Configure not to be able to find dlopen()
> (it's in /usr/include/dlfcn.h)? Could I be missing something else
> important?

How did you run Configure? You gave an example

> Via some Googling and experimentation, I finally figured out to
> build Perl with:
>
> sh Configure -des -Dusedl
>
> And then to enter ext/DynaLoader/dl_dlopen.xs" when prompted for
> dynamic loading. Then I update Makefile with:
>
> libs = -lnsl -ldl -lm -lcrypt -lutil -lc

But if you run Configure with the -d (use defaults) option, you
shouldn't get prompted for anything. Unless libraries and headers on
your system are in strange places -- and what you said in your mail
suggests that they are not -- Configure -d should find them. One
possibility is that there's a Policy.sh file left over in the build
directory from a previous botched build, and the values in that are
overriding the more sensible defaults that Configure would pick in
its absence. (See "Site-wide Policy settings" in INSTALL for
information about Policy.sh.)

To test my theory, can you try doing a clean default build of perl
like this:

rm -f config.sh Policy.sh
(sh Configure -de && make && make test) 2>&1 | tee perlbuild.log

That _should_ produce a perl that supports dynamic linking and passes
all tests.

If it doesn't, please attach a compressed copy of perlbuild.log to a
reply to this mail so that we can work out what's going wrong.
--
Dominic Dunlop
Re: dlopen() NOT found [ In reply to ]
On Wed, Jun 07, 2006 at 07:43:18PM -0700, David Wheeler wrote:
> Please excuse me if this is the wrong forum in which to inquire about
> a build issue. If there's some other list to which I should direct
> this inquiry, please let me know.

This is absolutely the right place.

> Via some Googling and experimentation, I finally figured out to build
> Perl with:
>
> sh Configure -des -Dusedl
>
> And then to enter ext/DynaLoader/dl_dlopen.xs" when prompted for
> dynamic loading. Then I update Makefile with:
>
> libs = -lnsl -ldl -lm -lcrypt -lutil -lc
>
> Now I have a 1.2 MB perl, which seems much better. But I have a new
> failing test:
>
> lib/ExtUtils/t/Embed......................../libperl.a(pp.o)(.text
> +0x272c): In function `Perl_pp_pow':
> : undefined reference to `pow'
> ../libperl.a(pp.o)(.text+0x346d): In function `Perl_pp_modulo':
> : undefined reference to `floor'
> ../libperl.a(pp.o)(.text+0x3495): In function `Perl_pp_modulo':
> : undefined reference to `floor'
> ../libperl.a(pp.o)(.text+0x355b): In function `Perl_pp_modulo':
> : undefined reference to `fmod'
> ../libperl.a(pp.o)(.text+0x7ce3): In function `Perl_pp_atan2':
> : undefined reference to `atan2'
> ../libperl.a(pp.o)(.text+0x7dc3): In function `Perl_pp_sin':
> : undefined reference to `sin'
> ../libperl.a(pp.o)(.text+0x7ee3): In function `Perl_pp_cos':
> : undefined reference to `cos'
> ../libperl.a(pp.o)(.text+0x8253): In function `Perl_pp_exp':
> : undefined reference to `exp'
> ../libperl.a(pp.o)(.text+0x83a5): In function `Perl_pp_log':
> : undefined reference to `log'
> ../libperl.a(pp.o)(.text+0x8577): In function `Perl_pp_sqrt':
> : undefined reference to `sqrt'
> ../libperl.a(pp.o)(.text+0x8728): In function `Perl_pp_int':
> : undefined reference to `ceil'
> ../libperl.a(pp.o)(.text+0x873e): In function `Perl_pp_int':
> : undefined reference to `floor'
> ../libperl.a(pp_pack.o)(.text+0x444c): In function `S_pack_rec':
> : undefined reference to `floor'
> ../libperl.a(pp_pack.o)(.text+0x4470): In function `S_pack_rec':
> : undefined reference to `floor'
> collect2: ld returned 1 exit status
> FAILED at test 1
>
> It seems curious that I would get these errors again since I've added
> -lm. But I can compile DBI and other C modules and they work again!

Adding it to perl's Makefile doesn't add it to the libraries used to
build extensions. If you absolutely can't get Configure to find the
libraries itself, add them to libs= and perllibs= (I think) in config.sh
when Configure asks if you want to edit config.sh.

But it would be much better to figure out what's going wrong in the
first place, starting with Dominic's suggestion.
Re: dlopen() NOT found [ In reply to ]
On Wed, Jun 07, 2006 at 07:43:18PM -0700, David Wheeler wrote:
> P5Pers,
>
> Please excuse me if this is the wrong forum in which to inquire about
> a build issue. If there's some other list to which I should direct
> this inquiry, please let me know.
>
> I had a hell of a time building Perl 5.8.8 on a 64 bit Red Hat
> Enterprise Linux ES release 4 box today. First, during `make`, I got
> these errors:

When you say "64 bit" does that mean that it has no 32 bit libraries
installed at all?

Or are they in /lib while the 64 bit versions are in /lib64?

What does -V on the system perl reveal about how RedHat configured *it*?

My hunch is that they passed it a load of -D options to change the library
search options. If so, it's a shame that those don't get rolled into hints
files and merged back upstream.

Nicholas Clark
Re: dlopen() NOT found [ In reply to ]
On 08/06/06, Nicholas Clark <nick@ccl4.org> wrote:
> When you say "64 bit" does that mean that it has no 32 bit libraries
> installed at all?
>
> Or are they in /lib while the 64 bit versions are in /lib64?
>
> What does -V on the system perl reveal about how RedHat configured *it*?
>
> My hunch is that they passed it a load of -D options to change the library
> search options. If so, it's a shame that those don't get rolled into hints
> files and merged back upstream.

Ooh that rings a bell. The Configure option would be libpth.

See the mandriva patch :
http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/~checkout~/SPECS/perl/perl-5.8.3-lib64.patch?rev=1.1.8.1&content-type=text/plain

This patch isn't clean since it introduces a new Configure variable
"lib". That should go to hints.
Re: dlopen() NOT found [ In reply to ]
On Thu, Jun 08, 2006 at 12:03:33PM +0200, Rafael Garcia-Suarez wrote:
> On 08/06/06, Nicholas Clark <nick@ccl4.org> wrote:
> >When you say "64 bit" does that mean that it has no 32 bit libraries
> >installed at all?
> >
> >Or are they in /lib while the 64 bit versions are in /lib64?
> >
> >What does -V on the system perl reveal about how RedHat configured *it*?
> >
> >My hunch is that they passed it a load of -D options to change the library
> >search options. If so, it's a shame that those don't get rolled into hints
> >files and merged back upstream.
>
> Ooh that rings a bell. The Configure option would be libpth.
>
> See the mandriva patch :
> http://cvs.mandriva.com/cgi-bin/cvsweb.cgi/~checkout~/SPECS/perl/perl-5.8.3-lib64.patch?rev=1.1.8.1&content-type=text/plain
>
> This patch isn't clean since it introduces a new Configure variable
> "lib". That should go to hints.

It certainly does ring bells. This is exactly the same problem seen in
RT #31676: Fail to compile. The ticket ends with a guest adding the
following statement.

"I see that you are building on an x86_64 platform. I had the same
problem during an LFS build on my x86_64 machine and found several
misleading clues via google. For me, the solution was hinted at in the
x86_64 LFS specific directions here
http://home.ix.netcom.com/~ejohns/glfs-amd64/base.html - but not
explicitly enough spelled out for me. The short of it is that on x86_64,
because the setup is biarch, the libraries you want to build against are
in /lib64 /usr/lib64 and (possibly) /usr/local/lib64. The hint on the
linked page simply says "use /lib64 instead of /lib where appropriate" -
the critical point for me was using ./Configure and at the point where
it asks where to search for libraries, instead of leaving the default
'/lib' or putting in '/lib64', as I first guessed - I put in '/lib64
/usr/lib64'. From there the build worked fine. While it is easy to argue
the wisdom of the whole /lib64 thing in the first place, I'd say the
perl's Configure could possibly be smart enough to figure out this quirk
and offer up a sane default."

I've not found another x86_64 to work with for a complete solution,
though.

Steve Peters
steve@fisharerojo.org
Re: dlopen() NOT found [ In reply to ]
On Jun 8, 2006, at 01:00, Dominic Dunlop wrote:

> But if you run Configure with the -d (use defaults) option, you
> shouldn't get prompted for anything.

Even with -d, I get prompted when I specify -Dusedl and Configure
can't find dlopen().

> Unless libraries and headers on your system are in strange places
> -- and what you said in your mail suggests that they are not --
> Configure -d should find them. One possibility is that there's a
> Policy.sh file left over in the build directory from a previous
> botched build, and the values in that are overriding the more
> sensible defaults that Configure would pick in its absence. (See
> "Site-wide Policy settings" in INSTALL for information about
> Policy.sh.)

I deleted Policy.sh and config.sh before each build.

> That _should_ produce a perl that supports dynamic linking and
> passes all tests.

It does not.

> If it doesn't, please attach a compressed copy of perlbuild.log to
> a reply to this mail so that we can work out what's going wrong.

Will do, after I make my way through the other replies to my inquiry.
It's true that dlopen() is just in /usr/include/dlfcn.h, but there
are a lot of headers in /usr/lib64 and whatnot. Who's idea was that,
anyway?

Best,

David
Re: dlopen() NOT found [ In reply to ]
On Jun 8, 2006, at 01:51, Yitzchak Scott-Thoennes wrote:

> This is absolutely the right place.

Thanks, Yitzchak.

> Adding it to perl's Makefile doesn't add it to the libraries used to
> build extensions. If you absolutely can't get Configure to find the
> libraries itself, add them to libs= and perllibs= (I think) in
> config.sh
> when Configure asks if you want to edit config.sh.

I imagine that it will only ask me that if I *don't* use -d, yes?
There are a lot of prompts to go through without -d. :-(

> But it would be much better to figure out what's going wrong in the
> first place, starting with Dominic's suggestion.

Agreed.

Best,

David
Re: dlopen() NOT found [ In reply to ]
On Jun 8, 2006, at 02:57, Nicholas Clark wrote:

> When you say "64 bit" does that mean that it has no 32 bit libraries
> installed at all?
>
> Or are they in /lib while the 64 bit versions are in /lib64?

Yes, that. There are libraries in /lib, /lib64, /usr/lib, /usr/
lib64, /usr/local/lib, and /usr/local/lib64. Crazy, eh?

> What does -V on the system perl reveal about how RedHat configured
> *it*?

$ /usr/bin/perl5.8.5 -V
Summary of my perl5 (revision 5 version 8 subversion 5) configuration:
Platform:
osname=linux, osvers=2.6.9-22.18.bz155725.elsmp, archname=x86_64-
linux-thread-multi
uname='linux hs20-bc1-7.build.redhat.com
2.6.9-22.18.bz155725.elsmp #1 smp thu nov 17 15:34:08 est 2005 x86_64
x86_64 x86_64 gnulinux '
config_args='-des -Doptimize=-O2 -g -pipe -m64 -Dversion=5.8.5 -
Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red
Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Dlibpth=/usr/local/
lib64 /lib64 /usr/lib64 -Dprivlib=/usr/lib/perl5/5.8.5 -Dsitelib=/usr/
lib/perl5/site_perl/5.8.5 -Dvendorlib=/usr/lib/perl5/vendor_perl/
5.8.5 -Darchlib=/usr/lib64/perl5/5.8.5/x86_64-linux-thread-multi -
Dsitearch=/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi -
Dvendorarch=/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-
multi -Darchname=x86_64-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -
Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -
Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -
Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -
Uversiononly -Dpager=/usr/bin/less -isr -Dinc_version_list=5.8.4
5.8.3 5.8.2 5.8.1 5.8.0'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define
usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=define use64bitall=define uselongdouble=undef
usemymalloc=n, bincompat5005=undef
Compiler:
cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-
strict-aliasing -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -
D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
optimize='-O2 -g -pipe -m64',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -fno-strict-
aliasing -pipe -I/usr/local/include -I/usr/include/gdbm'
ccversion='', gccversion='3.4.5 20051201 (Red Hat 3.4.5-1)',
gccosandvers=''
intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
ivtype='long', ivsize=8, nvtype='double', nvsize=8,
Off_t='off_t', lseeksize=8
alignbytes=8, prototype=define
Linker and Libraries:
ld='gcc', ldflags =''
libpth=/usr/local/lib64 /lib64 /usr/lib64
libs=-lnsl -lgdbm -ldb -ldl -lm -lcrypt -lutil -lpthread -lc
perllibs=-lnsl -ldl -lm -lcrypt -lutil -lpthread -lc
libc=/lib/libc-2.3.3.so, so=so, useshrplib=true, libperl=libperl.so
gnulibc_version='2.3.4'
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E
-Wl,-rpath,/usr/lib64/perl5/5.8.5/x86_64-linux-thread-multi/CORE'
cccdlflags='-fPIC', lddlflags='-shared'


Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING MULTIPLICITY USE_ITHREADS
USE_64_BIT_INT USE_64_BIT_ALL USE_LARGE_FILES PERL_IMPLICIT_CONTEXT
Built under linux
Compiled at Dec 16 2005 14:06:23
@INC:
/usr/lib64/perl5/5.8.5/x86_64-linux-thread-multi
/usr/lib/perl5/5.8.5
/usr/lib64/perl5/site_perl/5.8.5/x86_64-linux-thread-multi
/usr/lib64/perl5/site_perl/5.8.4/x86_64-linux-thread-multi
/usr/lib64/perl5/site_perl/5.8.3/x86_64-linux-thread-multi
/usr/lib64/perl5/site_perl/5.8.2/x86_64-linux-thread-multi
/usr/lib64/perl5/site_perl/5.8.1/x86_64-linux-thread-multi
/usr/lib64/perl5/site_perl/5.8.0/x86_64-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.5
/usr/lib/perl5/site_perl/5.8.4
/usr/lib/perl5/site_perl/5.8.3
/usr/lib/perl5/site_perl/5.8.2
/usr/lib/perl5/site_perl/5.8.1
/usr/lib/perl5/site_perl/5.8.0
/usr/lib/perl5/site_perl
/usr/lib64/perl5/vendor_perl/5.8.5/x86_64-linux-thread-multi
/usr/lib64/perl5/vendor_perl/5.8.4/x86_64-linux-thread-multi
/usr/lib64/perl5/vendor_perl/5.8.3/x86_64-linux-thread-multi
/usr/lib64/perl5/vendor_perl/5.8.2/x86_64-linux-thread-multi
/usr/lib64/perl5/vendor_perl/5.8.1/x86_64-linux-thread-multi
/usr/lib64/perl5/vendor_perl/5.8.0/x86_64-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.5
/usr/lib/perl5/vendor_perl/5.8.4
/usr/lib/perl5/vendor_perl/5.8.3
/usr/lib/perl5/vendor_perl/5.8.2
/usr/lib/perl5/vendor_perl/5.8.1
/usr/lib/perl5/vendor_perl/5.8.0
/usr/lib/perl5/vendor_perl
.

> My hunch is that they passed it a load of -D options to change the
> library
> search options. If so, it's a shame that those don't get rolled
> into hints
> files and merged back upstream.

Yep, you're absolutely right. There they are. How annoying.

Best,

David
Re: dlopen() NOT found [ In reply to ]
On Jun 8, 2006, at 05:24, Steve Peters wrote:

> I've not found another x86_64 to work with for a complete solution,
> though.

I wish I could give you access to this box, but it belongs to a
client, so I'm not sure they'd like that. But it's a rackspace box;
maybe someone at rackspace could make one available to the community
for a couple of days to resolve this issue?

Otherwise, if there are things you'd like me to do on this box and
send the output, I'd be glad to do so.

Meanwhile, prompted by Nick's post and what I saw in the vendor
perl's -V, I managed to get it to successfully compile and pass all
tests (except the UDP ping test) with:

sh Configure -des -Dlibpth="/usr/local/lib64 /lib64 /usr/lib64"

Do you want to see the output from that? (I created a log file using
Dominic's recipe and can compress it and send it along.) Thanks
everyone for your help; I greatly appreciate it!

Best,

David
Re: dlopen() NOT found [ In reply to ]
On Thu, 2006-06-08 at 10:07 -0700, David Wheeler wrote:
> On Jun 8, 2006, at 02:57, Nicholas Clark wrote:
>
> > When you say "64 bit" does that mean that it has no 32 bit libraries
> > installed at all?
> >
> > Or are they in /lib while the 64 bit versions are in /lib64?
>
> Yes, that. There are libraries in /lib, /lib64, /usr/lib, /usr/
> lib64, /usr/local/lib, and /usr/local/lib64. Crazy, eh?

Have you looked at the spec file used to build the original version?

The spec file has a patch for dealing with multi-arch systems and 64bit
libraries. It also forces the directories on the config line. (Not to
mention all the other patches that get done for various reasons.)

The reason for the split directories is so that you can mix 32bit and 64
bit binaries on the same machine. Handy if you have code that only runs
under 32 bit. (I have a couple of AMD64 machines. One is my laptop.)

Yes it is a pain, but so far there are not any better solutions at the
moment. (That I know of, at least.)
Re: dlopen() NOT found [ In reply to ]
On Jun 8, 2006, at 10:40, Alan Olsen wrote:

> Have you looked at the spec file used to build the original version?

Do you mean the vendor's build? Where would I look for it? What is it
called?

> The spec file has a patch for dealing with multi-arch systems and
> 64bit
> libraries. It also forces the directories on the config line.
> (Not to
> mention all the other patches that get done for various reasons.)

Heh, right.

> The reason for the split directories is so that you can mix 32bit
> and 64
> bit binaries on the same machine. Handy if you have code that only
> runs
> under 32 bit. (I have a couple of AMD64 machines. One is my laptop.)
>
> Yes it is a pain, but so far there are not any better solutions at the
> moment. (That I know of, at least.)

Yes, okay, that makes sense. It'd just be nice if the system could
somehow tell Configure where to find all this stuff so that every
application didn't ned to have its configuration script and/or
Makefile patched to support it.

Best,

David
Re: dlopen() NOT found [ In reply to ]
On Thu, 2006-06-08 at 10:25 -0700, David Wheeler wrote:
> On Jun 8, 2006, at 05:24, Steve Peters wrote:
>
> > I've not found another x86_64 to work with for a complete solution,
> > though.
>
> I wish I could give you access to this box, but it belongs to a
> client, so I'm not sure they'd like that. But it's a rackspace box;
> maybe someone at rackspace could make one available to the community
> for a couple of days to resolve this issue?
>
> Otherwise, if there are things you'd like me to do on this box and
> send the output, I'd be glad to do so.
>
> Meanwhile, prompted by Nick's post and what I saw in the vendor
> perl's -V, I managed to get it to successfully compile and pass all
> tests (except the UDP ping test) with:
>
> sh Configure -des -Dlibpth="/usr/local/lib64 /lib64 /usr/lib64"
>
> Do you want to see the output from that? (I created a log file using
> Dominic's recipe and can compress it and send it along.) Thanks
> everyone for your help; I greatly appreciate it!

Here is the configure section of the rpm (with macros included).

sh Configure -des -Doptimize="$RPM_OPT_FLAGS" \
-Dversion=%{perlver} \
-Dmyhostname=localhost \
-Dperladmin=root@localhost \
-Dcc='%{__cc}' \
-Dcf_by='Red Hat, Inc.' \
-Dinstallprefix=%{_prefix} \
-Dprefix=%{_prefix} \
%ifarch %{multilib_64_archs}
-Dlibpth="/usr/local/lib64 /lib64 /usr/lib64" \
-Dprivlib="/usr/lib/perl5/%{version}" \
-Dsitelib="/usr/lib/perl5/site_perl/%{version}" \
-Dvendorlib="/usr/lib/perl5/vendor_perl/%{version}" \

-Darchlib="%{_libdir}/perl5/%{perlver}/%{_arch}-%{_os}%{thread_arch}" \

-Dsitearch="%{_libdir}/perl5/site_perl/%{perlver}/%{_arch}-%{_os}%{thread_arch}" \

-Dvendorarch="%{_libdir}/perl5/vendor_perl/%{perlver}/%{_arch}-%{_os}%{thread_arch}" \
%endif
-Darchname=%{_arch}-%{_os} \
%ifarch sparc
-Ud_longdbl \
%endif
-Dvendorprefix=%{_prefix} \
-Dsiteprefix=%{_prefix} \
-Duseshrplib \
%if %threading
-Dusethreads \
-Duseithreads \
%else
-Uusethreads \
-Uuseithreads \
%endif
%if %largefiles
-Duselargefiles \
%else
-Uuselargefiles \
%endif
-Dd_dosuid \
-Dd_semctl_semun \
-Di_db \
-Ui_ndbm \
-Di_gdbm \
-Di_shadow \
-Di_syslog \
-Dman3ext=3pm \
-Duseperlio \
-Dinstallusrbinperl=n \
-Ubincompat5005 \
-Uversiononly \
-Dpager='/usr/bin/less -isr' \
-Dd_gethostent_r_proto -Ud_endhostent_r_proto
-Ud_sethostent_r_proto \
-Ud_endprotoent_r_proto -Ud_setprotoent_r_proto \
-Ud_endservent_r_proto -Ud_setservent_r_proto \
-Dinc_version_list='%{perlmodcompat}' \
-Dscriptdir='%{_bindir}'

The patch for lib64 hackery is as follows (probably mangled by
Evolution):


--- perl-5.8.0/Configure.orig 2002-09-09 11:31:19.000000000 -0400
+++ perl-5.8.0/Configure 2002-09-09 11:40:37.000000000 -0400
@@ -6458,8 +6458,8 @@
: Reproduce behavior of 5.005 and earlier, maybe drop that in 5.7.
case "$installstyle" in
'') case "$prefix" in
- *perl*) dflt='lib';;
- *) dflt='lib/perl5' ;;
+ *perl*) dflt='lib64';;
+ *) dflt='lib64/perl5' ;;
esac
;;
*) dflt="$installstyle" ;;
@@ -6475,8 +6475,8 @@
: /opt/perl/lib/perl5... would be redundant.
: The default "style" setting is made in installstyle.U
case "$installstyle" in
-*lib/perl5*) set dflt privlib lib/$package/$version ;;
-*) set dflt privlib lib/$version ;;
+*lib64/perl5*) set dflt privlib lib64/$package/$version ;;
+*) set dflt privlib lib64/$version ;;
esac
eval $prefixit
$cat <<EOM
@@ -6934,8 +6934,8 @@
prog=`echo $package | $sed 's/-*[0-9.]*$//'`
case "$sitelib" in
'') case "$installstyle" in
- *lib/perl5*) dflt=$siteprefix/lib/$package/site_
$prog/$version ;;
- *) dflt=$siteprefix/lib/site_$prog/$version ;;
+ *lib64/perl5*) dflt=$siteprefix/lib64/$package/site_
$prog/$version ;;
+ *) dflt=$siteprefix/lib64/site_$prog/$version ;;
esac
;;
*) dflt="$sitelib"
@@ -7061,8 +7061,8 @@
'')
prog=`echo $package | $sed 's/-*[0-9.]*$//'`
case "$installstyle" in
- *lib/perl5*) dflt=$vendorprefix/lib/$package/vendor_
$prog/$version ;;
- *) dflt=$vendorprefix/lib/vendor_
$prog/$version ;;
+ *lib64/perl5*) dflt=$vendorprefix/lib64/$package/vendor_
$prog/$version ;;
+ *) dflt=$vendorprefix/lib64/vendor_
$prog/$version ;;
esac
;;
*) dflt="$vendorlib"
Re: dlopen() NOT found [ In reply to ]
On Thu, 2006-06-08 at 10:44 -0700, David Wheeler wrote:
> On Jun 8, 2006, at 10:40, Alan Olsen wrote:
>
> > Have you looked at the spec file used to build the original version?
>
> Do you mean the vendor's build? Where would I look for it? What is it
> called?

It is in the src.rpm for perl.

ftp://mirrors.kernel.org/fedora/core/5/source/SRPMS/perl-5.8.8-4.src.rpm

rpm -ivh perl-5.8.8-4.src.rpm

The spec file will be in /usr/src/redhat/SPEC/perl.spec . (Unless you
have your rpm development environment set up differently, as you should.
The above path requires root to install. You should not build packages
as root.

If you want good information on RPM and spec files, I can find you a
couple of good references. (Useful if you deal with anything that uses
RPM as a package manager. That includes SuSE, Mandrake/Mandriva, etc.)

> > The spec file has a patch for dealing with multi-arch systems and
> > 64bit
> > libraries. It also forces the directories on the config line.
> > (Not to
> > mention all the other patches that get done for various reasons.)
>
> Heh, right.

Some of those patches are pretty important. Red Hat (and other vendors)
tend to backport security patches. Makes it a lot easier for the user
to not have to upgrade every Perl module they have just because a
security patch is in a later version of Perl than they currently have
installed. (Keeps the breakage down to smaller bitesized chunks.)

Most of the patches have a very good reason for being there. Some had a
good reason at one time, but are no longer a problem under the current
version. (Occasionally you will find patches that either never get
installed or are referenced and are commented out because they either no
longer work or are commented out or both.)

> > The reason for the split directories is so that you can mix 32bit
> > and 64
> > bit binaries on the same machine. Handy if you have code that only
> > runs
> > under 32 bit. (I have a couple of AMD64 machines. One is my laptop.)
> >
> > Yes it is a pain, but so far there are not any better solutions at the
> > moment. (That I know of, at least.)
>
> Yes, okay, that makes sense. It'd just be nice if the system could
> somehow tell Configure where to find all this stuff so that every
> application didn't ned to have its configuration script and/or
> Makefile patched to support it.

It does. The patches are for those cases where the configure script
makes assumptions about hardcoded locations. (Such as /usr/lib/.)

Perl is pretty sane for patches. There are a few other programs out
there that are not so nice. Some are unbuildable without patching. (And
not just under 64 bit either.) If you want to see an evil spec file
look at tetex.
Re: dlopen() NOT found [ In reply to ]
On Jun 8, 2006, at 11:04, Alan Olsen wrote:

> It is in the src.rpm for perl.
>
> ftp://mirrors.kernel.org/fedora/core/5/source/SRPMS/
> perl-5.8.8-4.src.rpm
>
> rpm -ivh perl-5.8.8-4.src.rpm
>
> The spec file will be in /usr/src/redhat/SPEC/perl.spec . (Unless you
> have your rpm development environment set up differently, as you
> should.
> The above path requires root to install. You should not build
> packages
> as root.

I don't have that file. I'm not building an RPM; I'm just building
Perl on this box for production use.

> If you want good information on RPM and spec files, I can find you a
> couple of good references. (Useful if you deal with anything that
> uses
> RPM as a package manager. That includes SuSE, Mandrake/Mandriva, etc.)

I'm just happy to get Perl to compile.

> Some of those patches are pretty important. Red Hat (and other
> vendors)
> tend to backport security patches. Makes it a lot easier for the user
> to not have to upgrade every Perl module they have just because a
> security patch is in a later version of Perl than they currently have
> installed. (Keeps the breakage down to smaller bitesized chunks.)

Sure. But I've never found Red Hat's Apache/mod_perl RPM to work very
well. So I always compile myself. I always compile myself, anyway.
I'm a glutton for punishment, I guess, but it has never really been
tricky for me until yesterday.

> Perl is pretty sane for patches. There are a few other programs out
> there that are not so nice. Some are unbuildable without patching.
> (And
> not just under 64 bit either.) If you want to see an evil spec file
> look at tetex.

Yes, there are a number of apps I have to patch when I build them; I
have a small library of them. But two that never give me problems are
Perl and PostgreSQL, and I'm *really* grateful for that, since they
are essential to my work.

Best,

David
Re: dlopen() NOT found [ In reply to ]
On Thu, 2006-06-08 at 11:08 -0700, David Wheeler wrote:
> On Jun 8, 2006, at 11:04, Alan Olsen wrote:
>
> > It is in the src.rpm for perl.
> >
> > ftp://mirrors.kernel.org/fedora/core/5/source/SRPMS/
> > perl-5.8.8-4.src.rpm
> >
> > rpm -ivh perl-5.8.8-4.src.rpm
> >
> > The spec file will be in /usr/src/redhat/SPEC/perl.spec . (Unless you
> > have your rpm development environment set up differently, as you
> > should.
> > The above path requires root to install. You should not build
> > packages
> > as root.
>
> I don't have that file. I'm not building an RPM; I'm just building
> Perl on this box for production use.

That is the file Red Hat used to build the original RPM. It shows you
how they got it to build.

> > If you want good information on RPM and spec files, I can find you a
> > couple of good references. (Useful if you deal with anything that
> > uses
> > RPM as a package manager. That includes SuSE, Mandrake/Mandriva, etc.)
>
> I'm just happy to get Perl to compile.

I always check the rpm just to find out what they did to get it to work.
You don't have to build an rpm. (Makes later dependancy handling better
however.)

> > Some of those patches are pretty important. Red Hat (and other
> > vendors)
> > tend to backport security patches. Makes it a lot easier for the user
> > to not have to upgrade every Perl module they have just because a
> > security patch is in a later version of Perl than they currently have
> > installed. (Keeps the breakage down to smaller bitesized chunks.)
>
> Sure. But I've never found Red Hat's Apache/mod_perl RPM to work very
> well.

Except in FC2 which has an unfixed bitbucket error that will run your
logs to overflowing. There is a patch if you have to run that version
due to old mod_perl 1.x code that won't work in compatibility mode.
(Which was broken in FC3.)

> So I always compile myself. I always compile myself, anyway.
> I'm a glutton for punishment, I guess, but it has never really been
> tricky for me until yesterday.

Been there. Done that. Now I just build my own distro (a heavily hacked
version of Fedora).

> > Perl is pretty sane for patches. There are a few other programs out
> > there that are not so nice. Some are unbuildable without patching.
> > (And
> > not just under 64 bit either.) If you want to see an evil spec file
> > look at tetex.
>
> Yes, there are a number of apps I have to patch when I build them; I
> have a small library of them. But two that never give me problems are
> Perl and PostgreSQL, and I'm *really* grateful for that, since they
> are essential to my work.

Perl has always been very good about builds. (With a few fixable
exceptions.) Lets me spend my time fighting other software issues.
Re: dlopen() NOT found [ In reply to ]
On Jun 8, 2006, at 11:21, Alan Olsen wrote:

> Perl has always been very good about builds. (With a few fixable
> exceptions.) Lets me spend my time fighting other software issues.

'Zactly!

Thanks,

David
Re: dlopen() NOT found [ In reply to ]
On Thu, Jun 08, 2006 at 10:04:50AM -0700, David Wheeler wrote:
> On Jun 8, 2006, at 01:51, Yitzchak Scott-Thoennes wrote:
>
> >This is absolutely the right place.
>
> Thanks, Yitzchak.
>
> >Adding it to perl's Makefile doesn't add it to the libraries used to
> >build extensions. If you absolutely can't get Configure to find the
> >libraries itself, add them to libs= and perllibs= (I think) in
> >config.sh
> >when Configure asks if you want to edit config.sh.
>
> I imagine that it will only ask me that if I *don't* use -d, yes?
> There are a lot of prompts to go through without -d. :-(

Nope, that particular prompt happens anyway, unless you specify -e :)