[Top][All Lists]

[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
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

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.


[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]