lzip-bug
[Top][All Lists]
Advanced

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

Re: [Lzip-bug] solaris compile errors, lzip, and plzip: error: stdint.h


From: Ersek, Laszlo
Subject: Re: [Lzip-bug] solaris compile errors, lzip, and plzip: error: stdint.h: No such file or directory
Date: Thu, 31 Dec 2009 18:52:06 +0100 (CET)

On Thu, 31 Dec 2009, rupert THURNER wrote:

On Mon, Dec 28, 2009 at 14:31, Antonio Diaz Diaz <address@hidden> wrote:

You can replace "#include <stdint.h>" with "#include <inttypes.h>". Both
headers are C99 provided as extensions in C++, but for some reason solaris
only provides inttypes.h.

<inttypes.h> is (also) SUSv2, see [0]. It appears to me that Rupert tries to build lzip on a SPARC Solaris 8. That platform is certified UNIX 98, see [1]. (Note that the certificate covers most probably the platform c89 compiler only.) SUSv2 doesn't say anything about C++ to my knowledge.


after patching the include files, linking fails with:

gmake[2]: Entering directory
`/home/rupert/mgar/pkg/lzlib/trunk/work/solaris8-sparc/build-isa-sparcv8/lzlib-0.8-rc1'
c++ -shared -Wl,--soname=liblz.so.0 -o liblz.so.0.8-rc1 sh_decoder.o
sh_encoder.o sh_lzlib.o
/usr/ccs/bin/ld: illegal option -- -
ld: warning: option -o appears more than once, first setting taken
usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VY:?] file(s)

This is because you don't use the GNU linker but the platform linker, and the platform linker chokes on "--soname=liblz.so.0". I figure since the c++ compiler itself didn't barf at "-Wl", you're actually using g++, which then passes the --soname option to the sun linker.

I'm not sure how one could portably fix this. One idea is to remove the -Wl parameter altogether, but I'm not experienced with shared libraries. SUSv2 at least doesn't seem to say anything on the matter. Nor does (the most recent) SUSv4, see [2]:

    -l library

      Search the library named liblibrary.a. A library shall be
      searched when its name is encountered, so the placement of a -l
      option is significant. Several standard libraries can be
      specified in this manner, as described in the EXTENDED
      DESCRIPTION section. Implementations may recognize
      implementation-defined suffixes other than .a as denoting
      libraries.

Thus the most recent Single Unix Specification (or rather, The Open Group Base Specifications Issue 7) doesn't seem to say anything about either C++ or shared libraries. You might have to patch the Makefile, or perhaps Antonio will turn to GNU libtool [3] and mark it as a build-time requisite.

Cheers,
lacos

[0] http://www.opengroup.org/onlinepubs/007908775/xsh/inttypes.h.html
[1] http://www.opengroup.org/openbrand/register/brand2695.htm
[2] http://www.opengroup.org/onlinepubs/9699919799/utilities/c99.html
[3] http://www.gnu.org/software/libtool/




reply via email to

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