|AWARE [SYSTEMS]||Imaging expertise for the Delphi developer|
|TIFF and LibTiff Mailing List Archive|
LibTiff Mailing List
1999.12.21 14:58 "libtiff and DSOs under AIX", by Andrew Furlong
Posting the results of this to the list for anyone who is interested. Originally sent this to Mike and Frank last week; Mike's response is attached at the bottom. I'm going to use the gcc compiler and bypass the DSOs entirely, it seems to be the simplest thing to do. Andrew > Hi, > > I think there may be a bug in the configure script for libtiff, with > respect to AIX 4.2.1 on RS6000 type machines. I've noted this on both > the 3.4 beta037 and 3.5.2 versions. > > I've compiled both versions of libtiff using both the C compilers we > have (gcc 2.8.1 and IBM's xlc, which is the standard 'cc'). The gcc we > have does not support DSO libraries, and for that version I have no > complaints. However, the xlc compiler does support DSOs, so the library > is generated as such and the tiff tools are compiled linking in the > library ../libtiff/libtiff.a. But when I try to run one of the tiff > tools (specifically tried tiffinfo), I get the following error: > > "Exec() failed: cannot execute tiffinfo for the following reasons: > cannot locate library ../libtiff/libtiff.a" > > This happens if I run the command from anywhere as "tiffinfo tiffile". > It also happens if I use the full pathname to the command. It doesn't > even work if I cd to the directory in which the command was installed, > and run it from there - unless for that directory the > ../libtiff/libtiff.a relative path is valid. > > There's no opportunity in the config script to reset the library link > step inclusion pathname to be a fullpath - or even just to the libtiff.a > filename, on the assumption that the LD_LIBRARY_PATH environment > variable is set properly to locate the libtiff.a once installed. > > Is this a bug? Is there a version released which corrects this? (Or am > I completely out to lunch here, which I admit is a possibility?) And Mike's response: > Here's the answer from my resident AIX expert. I'm inclined to follow > his advice. I, too, was never able to get Perl to build non-staticly. > How horriblle would this make the tools under AIX? > > > > Subject: > AIX box at home (forwarded message from Andrew Furlong) > Date: > Mon, 20 Dec 1999 15:44:44 -0500 (EST) > From: > "R. Bernstein" > To: > email@example.com > References: > 1 > > > > Funny, I was just about to junk the AIX box. (Recently I switched over > to using the Sun Box.) You are in luck in that it runs AIX 4.2.1. > > Of course, I use egcs. It looks like gcc 2.8.1 is the pre egcs/gcc > merged code. As for xlc, all I have is a very very old compiler back > from the AIX 3.x days when xlc was bundled with the operating system. > No way was I going to pay for a compiler even though I worked on > it. (Now if the guys had bought me lunch when I was leaving...) > > Anyway, enough of me and back to the problem at hand. Between the xlc > that I have and the one that you buy with AIX 4, the object format > changed. As you may recall, I've never been able to get shared object > support working with Perl. There is supposedly some sort of upward > compatibility between AIX 3 & 4 object formats. > > As for a "fix," probably the simplest thing is to force non-shared > libraries on AIX until someone knows how to fix. There is an ldd > for AIX. It is not part of the standard distribution, but from the guy > who's work was used to make Perl shared objects work. I think the > closes AIX equivalent is something like dump -h. Anyway the guy should > run that to see what it shows. And of course a log of the build > process would be nice. > > But if you are undaunted and want to waste countless hours on a (slow) > AIX box, with a little work, I could probably set you up an account > and put the thing on the net, but I'm not sure you really want to > start futzing around with AIX and shared library support which has > been a bit of black magic unless you have AIX 4 xlc. > > P.S. > rpm vs deb's forwarded to geek since it seems of general valuable use. > Mike, Thanks again for looking into this.