compile error with gcc-4.4, solaris, for http

2009-12-28
2013-05-30
  • rupert thurner
    rupert thurner
    2009-12-28

    while trying to create a solaris package for , we get the following compile error on solaris:

        ld: fatal: relocation error: R_386_GOTOFF: file .libs/liblzma_la-block_encoder.o: symbol lzma_block_encoder_init: relocation must bind locally
        gmake: ***  Error 1
        gmake: Leaving directory `/home/rupert/mgar/pkg/xz/trunk/work/solaris8-i386/build-isa-i386/xz-4.999.9beta/src/liblzma'
        gmake: ***  Error 1
        gmake: Leaving directory `/home/rupert/mgar/pkg/xz/trunk/work/solaris8-i386/build-isa-i386/xz-4.999.9beta/src/liblzma'
        gmake: ***  Error 1
        gmake: Leaving directory `/home/rupert/mgar/pkg/xz/trunk/work/solaris8-i386/build-isa-i386/xz-4.999.9beta/src'
        gmake: ***  Error 1
        gmake: Leaving directory `/home/rupert/mgar/pkg/xz/trunk/work/solaris8-i386/build-isa-i386/xz-4.999.9beta'
        gmake: ***  Error 2
        gmake: Leaving directory `/home/rupert/mgar/pkg/xz/trunk/work/solaris8-i386/build-isa-i386/xz-4.999.9beta'
        gmake: ***  Error 2
        gmake: Leaving directory `/home/rupert/mgar/pkg/xz/trunk'
        gmake: ***  Error 2
        gmake: Leaving directory `/home/rupert/mgar/pkg/xz/trunk'
        Connection to build8x closed.
        gmake: ***  Error 2
       
    we also found this:  with a similar error message.

      : http://opencsw.org
      : http://opensolaris.org/jive/thread.jspa?messageID=157350

     
  • Lasse Collin
    Lasse Collin
    2009-12-31

    I get an impression that it might be a bug in compiler or compiler + linker combination. You should be able to workaround the problem (but it's _not_ a real fix) by passing gl_cv_cc_visibility=no to configure. You could also try to another GCC version or some other compiler if possible.

     
  • I get this same error on Solaris 10 when using GCC 4.6.0 and Solaris ld.  GCC is configured like:

    configure LDFLAGS='-L/usr/local/lib -R/usr/local/lib' -program-suffix=-4.6.0 -enable-shared -enable-threads -enable-version-specific-runtime-libs -with-gnu-as -with-as=/usr/local/lib/binutils-2.21/bin/as -without-gnu-ld -with-ld=/usr/ccs/bin/ld -with-gmp=/usr/local -with-mpfr=/usr/local -with-mpc=/usr/local -with-ppl=/usr/local -with-cloog=/usr/local -with-cpu=opteron -enable-languages=c,c++,fortran

     
  • Under Solaris 10 on AMD_64 and building xz-5.0.3 I find it very strange that sparc.c is getting compiled.

     
  • Lasse Collin
    Lasse Collin
    2011-10-18

    Did the gl_cv_cc_visibility=no trick help? If yes, maybe I should enable it by default only on some operating systems.

    sparc.c contains BCJ filter for SPARC instructions. There's nothing weird about it being compiled.

     
  • The trick gets the library to compile but whatever it is doing seems suspect to me.  For example, when I attempt to build libtiff to use it using Sun's compiler (CC: Sun C++ 5.9 SunOS_i386 Patch 124864-26 2010/10/14), the link ends up with:

    ld: fatal: option -h and building a dynamic executable are incompatible
    ld: fatal: Flags processing errors
    gmake: ***  Error 1
    gmake: *** Waiting for unfinished jobs….
    cc: Warning: multiple use of -h option, previous one discarded.
    ld: warning: option -h appears more than once, first setting taken

    and this does not happen with the previous liblzma that I had built on the same machine in 2009.  The -h options are not supplied to the compiler (which is used to link) but it seems that the compiler intuits flags to pass to the linker based on the nature of the library object files thus it comes up the -h options (which don't work).

    I am able to link with the library using GCC.

     
  • Lasse Collin
    Lasse Collin
    2011-10-24

    Do you get the error even with gl_cv_cc_visibility=no?

    I tested "./configure CC=c99 && gmake check" on Solaris 10 SPARC, c99 being Sun's compiler. It worked fine. gl_cv_cc_visibility=no wasn't needed because configure correctly saw that visibility isn't supported with that compiler (at least not with GNU syntax).

    Maybe the problem only occurs on Solaris x86(-64). I'm not able to test on such a system now. Maybe I will be in the future. If the problem occurs even with gl_cv_cc_visibility=no and you didn't specify anything else than CC when running configure, it might be a libtool bug.

     
  • The library builds (and works) fine on Solaris x86 using Sun's compiler but not GCC using the Sun linker.  With GCC, gl_cv_cc_visibility=no does lead to a successful build, but something in the library triggers a problem (compiler generates and passes two -h options to linker) which prevents use with the Sun compiler (have not seen this with any other library in 4 years of experience).  There is no sign that libtool is causing the issue.

    This is the description of what -h does from the Sun ld manual page:

         -h name
         -soname name

             In dynamic mode only, when  building  a  shared  object,
             records  name  in  the object's dynamic section. name is
             recorded in any dynamic objects  that  are  linked  with
             this  object  rather than the object's file system name.
             Accordingly, name is used by the runtime linker  as  the
             name  of the shared object to search for at runtime. See
             Recording a Shared Object Name in Linker  and  Libraries
             Guide.

     
  • Lasse Collin
    Lasse Collin
    2011-10-28

    The -h option has the same meaning in GNU ld too. I don't use -h option directly; I let libtool handle it. So if -h gets specified twice, it might be a libtool issue. I will test it once I get access to Solaris x86. XZ Utils 5.0.3 builds fine with GCC 3.4.3 on Solaris 10 SPARC.