"Undefined symbol" error in Perl module that loads other shared libs

[fjliu2004]

Hi,

When I compiled a program (prog.c) that loads a shared lib (lib.so) to
be a standalone executable, it ran without any problems. However, when
I made prog.c into a Perl module, when it ran it complained that there
was an undefined symbol in lib.so and exited with status code 0177. Has
anyone encountered this problem before? I would appreciate it if
someone can share his/her solution with me.

Thanks in advance!

Frank

 

[Dr.Ruud]

(e-mail address removed) schreef:

When I compiled a program (prog.c) that loads a shared lib (lib.so) to
be a standalone executable, it ran without any problems. However, when
I made prog.c into a Perl module, when it ran it complained that there
was an undefined symbol in lib.so and exited with status code 0177.
Has anyone encountered this problem before? I would appreciate it if
someone can share his/her solution with me.

Maybe it finds a different version of the lib.so?

Can you show us a minimal program so that we can test ourselves?
Then also show a minimal part of the error messages.
Which symbol was mentioned as undefined?
Which platform are you working on?

 

[Tad McClellan]

I made prog.c into a Perl module,

Did you use the same compiler that was used to build your perl binary?

 

[fjliu2004]

Hi,

Thanks for the replies. Yes, I used the same compiler to compile my
program (prog.c) as the compiler used to build Perl. And there is only
one version of lib.so available, so Perl shouldn't have located a
different version.

I can't show the actual program here, though, because it's the
proprietary property of my employer. However, the error message Perl
displayed is as follows:

/usr/bin/perl: symbol lookup error:
/home/frank/work/oa/lib/linux_rhel21_32/opt/liboaRQXYTree.so: undefined
symbol: _ZNK12OpenAccess_413oaBlockageTbl14getLayerHeaderEj

liboaRQXYTree.so is called by lib.so, which is in turned called by my
Perl module (prog.c). When I compiled prog.c standalone, everything
worked fine, but when I compiled prog.c into a Perl module (which calls
lib.so which calls liboaRQXYTree.so), the error occurred. I'd
appreciate it if someone who knows why this happened can share the
reason with me.

Thanks for the help!

Frank

 

[Sisyphus]

Hi,

When I compiled a program (prog.c) that loads a shared lib (lib.so) to
be a standalone executable, it ran without any problems.

Curious - how does one link to a library named 'lib.so' ? Does '-l'
suffice, or does one need to specify '-llib' ?

However, when
I made prog.c into a Perl module, when it ran it complained that there
was an undefined symbol in lib.so and exited with status code 0177.

How did you create the perl module ? The usual way is to create a '.pm'
file, an '.xs' file, a Makefile.PL, and a test suite - and build by running
'perl Makefile.PL', 'make test', and 'make install'. Is that what you did ?
It would help if you could provide the actual error messages you received
during that process.

Did it complain that the "undefined symbol" was in "lib.so", or merely that
there was an "undefined symbol" ?

I assume the latter - which would imply that you haven't succesfully linked
to "lib.so".

It would also help if you could show us the output of 'perl -V', the actual
command you ran to build the "standalone executable", and the Makefile.PL
you used to build the Perl module.

Cheers,
Rob

 

[fjliu2004]

Dear Rob:

Sorry - "lib.so" is only a moniker. The actual shared lib name is
"liboaDesign.so".

I created the Perl module using SWIG. SWIG automatically generates a
"wrapper" for the module, which I compile along with my main C program
to make it into a Perl module.

The actual error message displayed is

/usr/bin/perl: symbol lookup error:
/home/frank/work/oa/lib/linux_rhel21_32/opt/liboaRQXYTree.so: undefined
symbol: _ZNK12OpenAccess_413oaBlockageTbl14getLayerHeaderEj

so it does show the lib in which the undefined symbol is.

liboaRQXYTree.so is called by lib.so, which is in turned called by my
Perl module (prog.c). When I compiled prog.c standalone, everything
worked fine, but when I compiled prog.c into a Perl module (which calls
lib.so which calls liboaRQXYTree.so), the error occurred.

Thanks,

Frank

 

[Sisyphus]

Dear Rob:

Sorry - "lib.so" is only a moniker. The actual shared lib name is
"liboaDesign.so".

I created the Perl module using SWIG.

I've not used SWIG - which probably limits my capacity to provide useful
assistance

It seems to me that, when you've built the executable, you've successfully
linked to the necessary libraries - probably using the '-L' and '-l'
switches.
But now that you're building the perl extension, you're failing to link to
one of those necessary libraries - namely the library that defines
_ZNK12OpenAccess_413oaBlockageTbl14getLayerHeaderEj .

Which library defines that symbol ?
Has the header file that prototypes
_ZNK12OpenAccess_413oaBlockageTbl14getLayerHeaderEj been #include'd ?

I would be trying to ensure that:
1) every header file that was #include'd when I built the executable is also
being #include'd when the perl module is being built;
2) every library that was linked in when I built the executable is also
being linked in when the perl module is being built.

If you can do that, then I *think* it should all be fine.

Cheers,
Rob

 

[fjliu2004]

Dear Rob:

Thanks for the reply. It turns out that I have to include an extra
library (say -lXYTree) that liboaDesign.so calls to make the whole
thing work in Perl. I don't know why this is the case, since
liboaDesign.so calls libXYTree.so, and I have already included
-loaDesign when I created the shared lib. Also, when I created the
standalone executable I didn't include -lXYTree and it ran without any
problems. Anyway, I'm just glad that it finally works. Thanks again for
the help!

Frank