Menu

How to get true shared library?

mef
2008-04-17
2013-05-28
  • mef

    mef - 2008-04-17

    I'm trying to compile mcpp 2.7 as a shared library on Fedora 8. Weirdly, even though -- as far as I can tell -- everything is using -fPIC where it should, it seems that the resulting .so is *not* PIC. At least, "readelf -d libmcpp.so.0.1.0" includes the line:
         0x00000016 (TEXTREL)                    0x0
    which as far as I can tell indicates that the object still requires relocations and is *not* PIC.

    Why is this the case? Is it possible to change this?

     
    • Kiyoshi Matsui

      Kiyoshi Matsui - 2008-04-18

      Thanks for the bug report.

      I compiled libmcpp of some versions with 'configure --enable-mcpplib; make' by GCC 4.1.*, and checked the generated libmcpp.so by readelf.  The results are:

      V.2.6.3:        PIC
      V.2.6.4:        PIC
      V.2.7:          non-PIC
      revision 97:    PIC

      Then I recompiled V.2.7 after patching as:
          -------------------------------------------
      --- internal.H.orig     2008-03-12 01:04:07.000000000 +0900
      +++ internal.H  2008-04-18 17:08:25.000000000 +0900
      @@ -526,7 +526,7 @@
                       /* Do the final commands        */
      extern void     print_heap( void);
                       /* Print blocks of heap memory  */
      -#if ! HOST_HAVE_STPCPY || HOST_COMPILER == GNUC
      +#if ! HOST_HAVE_STPCPY
      extern char *   stpcpy( char * dest, const char * src);
                       /* Non-Standard library function*/
      #endif
          -------------------------------------------

      Though GCC emits many warnings of "incompatible implicit declaration of built-in function 'stpcpy'", the generated libmcpp is reported PIC by readelf.

      I suppose that this is a problem of GCC (or ld?).  mcpp V.2.7 uses '#pragma GCC visibility *' directive, and GCC mis-handles its built-in stpcpy() under this directive.  GCC 4.3.0 even fails to generate libmcpp.so in link phase.

      The revision 97 of mcpp uses mcpp's own stpcpy() for libmcpp on GCC to avoid the problem of GCC.  I recommend to use mcpp revision 97, or V.2.7 with the above patch.

       
    • Kiyoshi Matsui

      Kiyoshi Matsui - 2008-04-20

      About the declaration problem of stpcpy():

      The problem was not a bug of GCC, but it was a bug of internal.H.
      When I revised it as (against V.2.7):

          -------------------------------------------
      --- internal.H.orig     2008-03-12 01:04:07.000000000 +0900
      +++ internal.H  2008-04-20 16:55:42.000000000 +0900
      @@ -526,7 +526,7 @@
                       /* Do the final commands        */
      extern void     print_heap( void);
                       /* Print blocks of heap memory  */
      -#if ! HOST_HAVE_STPCPY || HOST_COMPILER == GNUC
      +#if ! HOST_HAVE_STPCPY
      extern char *   stpcpy( char * dest, const char * src);
                       /* Non-Standard library function*/
      #endif
      @@ -552,3 +552,7 @@
      #pragma GCC visibility pop
      #endif
      #endif
      +
      +#if HOST_HAVE_STPCPY
      +extern char *   stpcpy( char * dest, const char * src);
      +#endif
          -------------------------------------------

      , GCC worked without any problem nor warning in building libmcpp.
      The declaration of stpcpy() should not be placed in "hidden" block, if it is not mcpp's own stpcpy().

      This patch will lose its indentation on the Web. Please edit the file by hand.
      mcpp of SVN revision 98 already incorporated the patch.
      The revision 98 also fixed a problem of predefined macro handling for x86_64 and ppc64 on GCC-specific-build.

       

Log in to post a comment.