libstdc++ problem with ExtUtils::MakeMaker

[sherlock]

Hi,

The GO::TermFinder modules
(http://search.cpan.org/dist/GO-TermFinder/), which I wrote, often seem
to have problems (platform dependent) when doing the make step,
specifically compiling the swig code in the 'native' directory. The
Makefile.PL in that directory has:

'LIBS' => ['-lm -lstdc++'],

but when the make is run, I see a complaint:

Note (probably harmless): No library found for -lstdc++

which later results in failures like:

# 'Can't load
'/Users/sherlock/dev/GO-TermFinder/blib/arch/auto/GO/TermFinder/Native/Native.bundle'
for module GO::TermFinder::Native:
dlopen(/Users/sherlock/dev/GO-TermFinder/blib/arch/auto/GO/TermFinder/Native/Native.bundle,
2): Symbol not found: __ZSt18_Rb_tree_decrementPSt18_Rb_tree_node_base

during the make test phase. If however, I look at the generated
Makefile in the native directory, I see:

LDLOADLIBS = -lm

if I change this to:

LDLOADLIBS = -lm -lstdc++

and redo the make, the problem is fixed. It is of course annoying to
tell people they may need to hand-edit make files during the
installation process. Does anyone know what I'm doing wrong in the
Makefile.PL file that might remedy the problem?

In this example, I was running Perl 5.8.8 on OSX 10.4.7, with
ExtUtils::MakeMaker 6.17 - I have seen this exact same problem on other
platforms though,

Many thanks in advance,
Gavin

 

[Sisyphus]

Hi,

The GO::TermFinder modules
(http://search.cpan.org/dist/GO-TermFinder/), which I wrote, often seem
to have problems (platform dependent) when doing the make step,
specifically compiling the swig code in the 'native' directory. The
Makefile.PL in that directory has:

'LIBS' => ['-lm -lstdc++'],

but when the make is run, I see a complaint:

Note (probably harmless): No library found for -lstdc++ ..
..
If however, I look at the generated
Makefile in the native directory, I see:

LDLOADLIBS = -lm

Yep, '-lstdc++' is not added to LDLOADLIBS because that library could not be
found when running the Makefile.PL. (If it had been found it *would* have
been added.)
And yet, the library is obviously present and *can* be located by the build
('make') process. The question therefore becomes "Why is the stdc++ library
not located by the 'perl Makefile.PL" process ?"

I don't know the answer, but the ExtUtils::LibList documentation may help
you to devise some tests that you can run on the problem platform(s) to
determine the cause.

Cheers,
Rob

 

[sherlock]

Hi Rob,

Thanks for the reply. Using :

perl -e 'require ExtUtils::Liblist; ExtUtils::Liblist->ext("-lstdc++",
1, 1);'

I get:

Potential libraries are '-lstdc++':
stdc++ not found in /usr/local/lib
stdc++ not found in /usr/lib
Note (probably harmless): No library found for -lstdc++

poking around in /usr/lib, I see:

libstdc++-static.a
libstdc++.6.0.3.dylib*
libstdc++.6.0.4.dylib*
libstdc++.6.dylib@ -> libstdc++.6.0.4.dylib

but this is where my ignorance prevents me from knowing if this is what
I'm looking for. Poking around a little further, there is also:

/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libstdc++.dylib

which probably is what I want, and the compiler seems to know how to
find when given the -lstdc++ flag, but MakeMaker doesn't know how to
find, so won't provide the flag (in fact this is a link to
libstdc++.6.dylib back in the /usr/lib directory).

I'll also try asking the unix porting group over on the Apple pages,

Cheers,
Gavin

Hi,

The GO::TermFinder modules
(http://search.cpan.org/dist/GO-TermFinder/), which I wrote, often seem
to have problems (platform dependent) when doing the make step,
specifically compiling the swig code in the 'native' directory. The
Makefile.PL in that directory has:

'LIBS' => ['-lm -lstdc++'],

but when the make is run, I see a complaint:

Note (probably harmless): No library found for -lstdc++ .
.
If however, I look at the generated
Makefile in the native directory, I see:

LDLOADLIBS = -lm

Yep, '-lstdc++' is not added to LDLOADLIBS because that library could not be
found when running the Makefile.PL. (If it had been found it *would* have
been added.)
And yet, the library is obviously present and *can* be located by the build
('make') process. The question therefore becomes "Why is the stdc++ library
not located by the 'perl Makefile.PL" process ?"

I don't know the answer, but the ExtUtils::LibList documentation may help
you to devise some tests that you can run on the problem platform(s) to
determine the cause.

Cheers,
Rob

 

[sherlock]

The answer I got on the MacOSX porting list was:

You need to somehow get perl to use g++ to link the module instead of
gcc. You'll probably need to use some tool to detect the platform c++
compiler and then use that. I'll suggest autoconf et. al. but many
people seem to have some kind of religious thing against the autotools,
so use whatever is apropriate.

but I'm don't really know how to implement that advice, and a search of
the MakeMaker docs doesn't find any reference to gcc or g++, so I don't
know if I can use MakeMaker to specify g++ instead of gcc. If anyone
has any follow up advice, it would be much appreciated,

Cheers,
Gavin

Hi Rob,

Thanks for the reply. Using :

perl -e 'require ExtUtils::Liblist; ExtUtils::Liblist->ext("-lstdc++",
1, 1);'

I get:

Potential libraries are '-lstdc++':
stdc++ not found in /usr/local/lib
stdc++ not found in /usr/lib
Note (probably harmless): No library found for -lstdc++

poking around in /usr/lib, I see:

libstdc++-static.a
libstdc++.6.0.3.dylib*
libstdc++.6.0.4.dylib*
libstdc++.6.dylib@ -> libstdc++.6.0.4.dylib

but this is where my ignorance prevents me from knowing if this is what
I'm looking for. Poking around a little further, there is also:

/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libstdc++.dylib

which probably is what I want, and the compiler seems to know how to
find when given the -lstdc++ flag, but MakeMaker doesn't know how to
find, so won't provide the flag (in fact this is a link to
libstdc++.6.dylib back in the /usr/lib directory).

I'll also try asking the unix porting group over on the Apple pages,

Cheers,
Gavin

Hi,

The GO::TermFinder modules
(http://search.cpan.org/dist/GO-TermFinder/), which I wrote, often seem
to have problems (platform dependent) when doing the make step,
specifically compiling the swig code in the 'native' directory. The
Makefile.PL in that directory has:

'LIBS' => ['-lm -lstdc++'],

but when the make is run, I see a complaint:

Note (probably harmless): No library found for -lstdc++ .
.
If however, I look at the generated
Makefile in the native directory, I see:

LDLOADLIBS = -lm

Yep, '-lstdc++' is not added to LDLOADLIBS because that library could not be
found when running the Makefile.PL. (If it had been found it *would* have
been added.)
And yet, the library is obviously present and *can* be located by the build
('make') process. The question therefore becomes "Why is the stdc++ library
not located by the 'perl Makefile.PL" process ?"

I don't know the answer, but the ExtUtils::LibList documentation may help
you to devise some tests that you can run on the problem platform(s) to
determine the cause.

Cheers,
Rob

 

[Sisyphus]

Hi Rob,

Thanks for the reply. Using :

perl -e 'require ExtUtils::Liblist; ExtUtils::Liblist->ext("-lstdc++",
1, 1);'

I get:

Potential libraries are '-lstdc++':
stdc++ not found in /usr/local/lib
stdc++ not found in /usr/lib
Note (probably harmless): No library found for -lstdc++

Hmmm ... I get:

Potential libraries are '-lstdc++':
stdc++ not found in /usr/local/lib
stdc++ not found in /lib
'-lstdc++' found at /usr/lib/libstdc++.so.5.0.3

poking around in /usr/lib, I see:

libstdc++-static.a
libstdc++.6.0.3.dylib*
libstdc++.6.0.4.dylib*
libstdc++.6.dylib@ -> libstdc++.6.0.4.dylib

but this is where my ignorance prevents me from knowing if this is what
I'm looking for.

I'm no expert either but, based upon what I got, I would guess that one of
those dynamic libraries needs to be found - and doesn't get found because
perl doesn't know how it's supposed to ignore certain bits of the extension.
(Otoh, the compiler *does* know all about those extensions, and finds the
correct file in /usr/lib.)

Poking around a little further, there is also:

/usr/lib/gcc/powerpc-apple-darwin8/4.0.1/libstdc++.dylib

which probably is what I want

It would be handy to know for sure just which file the linker is finding
when the '-lstdc++' switch is supplied. I'm not sure of a way to do that.

I'll also try asking the unix porting group over on the Apple pages,

I couldn't see a lot of value in what they came up with .... though my
eyesight is far from perfect

Cheers,
Rob