Re: Build problems om Solaris

[f95-msv f kth se (Mårten Svantesson)]

I'll start by clarifying that I ran the configure script that came
with 0.90RC1 straight up; autogen.sh wasn't run. 

Cyrille Chepelov <cyrille@chepelov.org> writes:

> Le Fri, May 24, 2002, ā 11:01:31PM +0200, Mårten Svantesson a écrit:
> > I had a few problems with building dia 0.90RC1 on Solaris 8, mostly
> > problems with the configure script:
> > 
> > The test for xml2 failed due to a syntax error. I fixed this problem
> > by editing the configure script to be run by bash instead of Bourne
> > shell.
> 
> Bashisms are the disease of Linux-originated scripts. It is very possible
> that this specific bashism is due to the libxml2 M4 macros; it may be our
> usage of them. Can you track down the exact changes ?

Maybe I wasn't clear: The only thing I changed was the "#! /bin/sh" to
"#! /bin/bash" on the first line. This changed the output from the
configure script for the xml2 checks from:

./configure: !: execute permission denied
./configure: !: execute permission denied

to

checking for xml2-config... xml2-config
checking for libxml >= 2.3.9... found

Nothing show up in config.log from the run with /bin/sh.
The suspects are:

"if ! $found_libxml; then" on line 8971
"if ! $found_libxml; then" on line 9028


> > The configure script didn't find an implementation to isinf, but
> > neither took any action to compensate, nor did it issue an error
> > message. Because of this the symbol isinf ended up being undefined in
> > the linking. This is a bit odd since the configure script found the
> > ieeefp.h header-file (wich include the function finite) and could
> > therefore have set a macro to activate a snippet in dia_xml.c like:
> > 
> > #ifdef IEEEFP
> > #include <ieeefp.h>
> > #define isinf(a) (! finite(a))
> > #endif
> 
> Yes, indeed. I'll try to fix that before the next tarball.

Fine. As far as I can se this problem is actually the only one of my
problems that is your fault.
 
> > A problem that is really a bug in libtool has to do with hard
> > linking. The filesystem I mostly use is AFS. AFS has the peculiarity
> > that hard linking is possible within a directory but not between
> > directories. In the configure script there is a test wether hard
> > linking is possible, unfortunately this is done within a directory. In
> > the build process on the other hand linking is done between
> > directories. Go figure. :-(
> 
> Hard linking is a Bad Thing generally speaking (there are situations where
> it is okay, but I'm hard pressed to find one). Hard linking across
> directories is almost always a no-no, because each directory could
> potentially be a mount point. I guess libtool is doing it because it
> hardlinks between a directory an a subdirectory of it it has mkdir'd itself,
> which makes it believe it's on the same partition. I'm afraid this means
> libtool expects some POSIX behaviour AFS doesn't have. Which version of
> libtool are you using (if you ran autogen.sh; if you didn't, I know which
> libtool you've used) ? 
> 
> If we can't fix this issue with libtool on solaris (by talking to the
> libtool guys), I'm afraid the only fix is to document against building on an
> AFS partition (just like you don't build on a vfat partition).

Another fix is to run configure with --disable-libtool-lock, since
it's for locking libtool use hard links. Libtool makes a lockfile by
making a hard link to itself. My own fix was handediting the libtool
script to make the link to the sourcefile instead. That worked fine.


> > > There also seem to be a bug in the check for libpng. After that check
> > > all compilations done by configure is done with "-lpng -lz" on the
> > > command-line. This leads failings in all these compilations:
> > > 
> > > "configure:9508: gcc -o conftest     conftest.c -lpng  -lz 1>&5
> > > Undefined                       first referenced
> > >  symbol                             in file
> > > pow                                 /opt/gnome-1.4/lib/libpng.so
> > > ld: fatal: Symbol referencing errors. No output written to conftest"
> > 
> > what version of libpng, and what version of the libpng-devel stuff ?
> > (assuming there is a mismatch).

As I mentioned I just ran the ./configure script in the tar. I can't
se how the versions of libpng stuff on my system could have any
significance.

> curiously, all tests for png in the configure script do add -lz -lm; that's
> really strange.... 

No, on line 7121 you have 'LIBS="-lpng $LIBS"'. That assignment is never
reseted, and thus is used onwards in the script. The same holds for
'LIBS="-lz  $LIBS"' on line 9079, but that causes no problem since libz
don't depend on other libraries. 


> > The simplest hack to go around this problem was to set CFLAG=-lm prior
> > to running configure.
> 
> Uh. This means your #define isinf will have trouble as well, since finite()
> is defined in libm, isn't it? Looks like we need to include libm for dia
> proper, anyway.

Actually not, on Solaris finite is defined in libc. If thats always
been the case on Solaris I don't know.

-- 
                - Mårten
 
mail: msv@kth.se *** phone:  +46 (0)8 7529933
ICQ:  4356928    *** mobile: +46 (0)707390385