Unresolved mcount profiling solaris dynamic library (gcc 3.1)

Hello all,

I have built executables and static libraries with the compiler and linker "-pg" option in order to get profile information. That's ok.

Now I am trying to build a dynamic library in the same way, but I am getting the following linker error:

Undefined                       first referenced
 symbol                             in file
_mcount                             obj/cstring.o
ld: warning: Symbol referencing errors

The whole linker command (once every file has been compiled) is the one showed here:

g++ -shared -dynamic -Wl,-z,now -Wl,-B,symbolic -pg -Wl,-h,libcstring.so.2.6 obj/cstring.o obj/argument.o obj/getpassword.o obj/mapass.o obj/witherror.o -olib/libcstring.so.2.6

I have searched for help for some days in news groups and search engines and I have seen this question posted multiple times but never solved.

Some help would be appreciated.

Best regards,
Who is Participating?
JasonTheGreatConnect With a Mentor Commented:

Based on the other question you posted I'm going to assume you're still on a Solaris machine.

There is bad news and good news.  Let's start with the bad but don't despair, the good news will trump the bad.

Unfortunately, dynamic libraries don't support the -pg option.  The gprof(1) man page is pretty clear about that.  From the NOTES section of the gprof(1) man page under the 32-bit profiling section:

"...   In 32-bit profiling, shared
     objects cannot be profiled with gprof.  Thus,  when  a  pro-
     filed,  dynamically  linked  program  is  executed, only the
     "main" portion of the image is sampled. "

And further on:

"... If  desired,  the
     program  should  be  linked  to  the  profiled  version of a
     library (or to the standard archive version if no  profiling
     version  is  available), instead of the shared object to get
     profile information on the functions of a library.  "

This was a bugger for me because our software uses dynamic loading to load plug-ins all the time.  Our main application is just a shell that loads the first dynamic library.

We eventually went on to use Rational's Quantify, which does support shared libraries (it supports Forte; I don't know about g++).  Expensive, but definitely worth the money if you have it in your budget (as well as Purify and Clearcase -- and no, I do not and have never had ties with Atria or Rational :).

If you don't have to profile with shared objects and can get away with profiling static objects, that would be my first recommendation.  

If you must dynamic libraries (as my group does), there are two other options you can try (sorry, but I haven't tried either one):

#1) Compile as normal and put that library in the LD_PROFILE environment variable.  From the ld.so.1(1) man page on Solaris 8:

           Defines a shared object that will be profiled  by  the
           runtime linker. When profiling is enabled, a profiling
           buffer file is created and mapped.  The  name  of  the
           buffer  file  is  the  name of the shared object being
           profiled with a .profile extension. By  default,  this
           buffer is placed under /var/tmp. The environment vari-
           able LD_PROFILE_OUTPUT may also be supplied  to  indi-
           cate  an  alternative  directory in which to place the
           profiling buffer.

           This buffer contains profil(2) and call count informa-
           tion  similar to the gmon.out information generated by
           programs that have been linked with the -xpg option of
           cc.  Any applications that use the named shared object
           and run while this environment variable  is  set  will
           accumulate  data  in  the  profile buffer. The profile
           buffer information may be examined using gprof(1).

           Notice that this profiling technique is an alternative
           to any that may be provided by the compilation system.
           The shared object being profiled does not have  to  be
           instrumented  in any way, and LD_PROFILE should not be
           combined with a profile-instrumented application."

  Note that last paragraph:  LD_PROFILE shouldn't be combined with a profile-instrumented application.  Bummer.  It's a start, though.

#2) Compile using 64-bit options.

Once again, from the gprof(1) man page:

"64-bit profiling
     64-bit profiling may be used freely with dynamically  linked
     executables,  and profiling information is collected for the
     shared objects if the objects are  compiled  for  profiling."

64-bit compilation brings on a whole other set of issues but if your code is pretty clean and you're using a recent version of g++ it should be possible.

In conclusion, your options are to buy Rational Quantify, use the LD_PROFILE environment variable, or compile using 64-bit options.

Hope this helps.


Dear davidjava

I think you forgot this question. I will ask Community Support to close it unless you finalize it within 7 days. You can always request to keep this question open. But remember, experts can only help you if you provide feedback to their questions.
Unless there is objection or further activity,  I will suggest to accept


comment(s) as an answer.

Force accepted

** Mindphaser - Community Support Moderator **
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.