bug-cgicc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Problem running dynamically linked objects with GCC V3


From: Becker, Monte
Subject: Problem running dynamically linked objects with GCC V3
Date: Mon, 18 Mar 2002 14:53:55 -0500

Hi there:

        I'm having a problem with dynamically link sharable libraries
using GCC V3.0 and SunOS v5.8 (64 bit).  I am able to link the dynamic
library into the main executable ok, and reference some functions in
the library.  However, execution fails if the library tries to access
a symbol in the main executable.  

        My test case is attached below.  Compilation instructions are
included.  I used 2 Sun systems running SunOS v5.8, which is 64 bit.
One system uses gcc 2.8.1, the other gcc 3.0.3.  

        When I compiled with 2.8.1, the resulting executable and
library ran on both systems.  This is the output when the test works
correctly:

                Hello from a sharable/dynamically loadable object
                4*2 = 8
                3*2 = 6
                Hello from functionFromMain

        With 3.0.3:

                Hello from a sharable/dynamically loadable object
                4*2 = 8
                3*2 = 6
                ld.so.1: dlHellowWorldFunc: fatal: relocation error: file
./dlHellowWorldFunc.so: symbol functionFromMain: referenced symbol not found
                Killed
                
        Since the image compiled with V2.8.1 runs on both system, it
seems likely the difference must be related to the compilation in some
way....  I first asked myself, is there a dlHellowWorldFunc symbol in
the main executable created by V3.0.3?

                nm -A dlHellowWorldFunc | grep functionFromMain
                dlHellowWorldFunc:0000000000010a90 T functionFromMain

        Yup.  Here's the same command for a V2.8.1 executable:

                nm -A dlHellowWorldFunc | grep functionFromMain
                dlHellowWorldFunc:00010a64 T functionFromMain

        One obvious difference is that the address created for V3.0.3
is 64 bits wide.  So, is this a bug with the sparc dynamic loader
(ld.so.1)?  Any suggestions?
        


        On an unrelated topic, or only slightly related...  I noticed
that I always see the __gxx_personality_v0 symbol when I create
sharable objects.  I believe, empirically, that when this symbol is in 
an object, the g++ executable must be used to for linking.  (Or, at
least, that makes it much easier to link.)  My example below has some
g++ features, but this is still a problem when I totally clean it up.
Is this the intended behavior?  If so, why?


        
        Many thanks in advance,

                Regards,


                        Monte








======================================= 
This email message is for the sole use of the intended recipient (s) and may
contain confidential and privileged information, including without
limitation, Confidential and/or Proprietary Information belonging to
Unisphere Networks, Inc. Any unauthorized review, use, disclosure or
distribution is prohibited. If you are not the intended recipient, please
contact the sender by reply email and destroy all copies of the original
message.
  

Attachment: dlHelloWorld.cc
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]