Re: [Lzip-bug] solaris compile errors, lzip, and plzip: error: stdint.h: No such file or directory

[Ersek, Laszlo]

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/