[cgma-dev] build issues, libtool

[Jed Brown]

Jason Kraftcheck wrote:
> Jed Brown wrote:
>> My system is automake 1.11, autoconf 2.64, libtool 2.2.6a, gcc 4.4.1.  I
>> pulled the most recent CGM (r3134), ran autoreconf -fi, and then
>> subsequently hit some build issues.  I don't know if this is due to new
>> versions on my end, or updates to CGM in the last couple months
>> (changelog suggests the former, but I'd rather not revert my environment
>> to confirm this unless it's important).
>>
> 
> I cannot reproduce the issues you see below.  More comments below.  I tried
> using automake 1.10.1 and autoconf 2.61 with both version 1.5.26 and 2.2.6a
> of libtool.  I think something is wrong with your libtool installation.

This could be, but other autotools projects are building just fine.
FWIW, autoreconf -fi produces a lot more warnings now than it has in the
past.  Are you sure the newer versions of automake and autoconf aren't
causing the problem?

>> First, configuring using --with-pic isn't actually adding -fPIC where
>> needed, I had to put this into *FLAGS.  My configuration is now
>>
> 
> You should never need to specify --with-pic.  Libtool automatically adds
> that for shared libraries.  The option is used to request PIC code in static
> libraries (*.a) that will later be linked into a shared library.

Right, I haven't needed to specify it in the past.  But if configured
--with-pic, -fPIC should be used for everything, but it isn't and that's
giving me build errors.

> 
> 
>>   ../configure --enable-shared --without-acis --prefix=/home/jed/usr --with-occ=/opt/opencascade --enable-debug --with-pic CFLAGS=-fPIC CXXFLAGS=-fPIC FCFLAGS=-fPIC
>>
>> More importantly, the libtool script that autoconf puts in the build
>> directory is broken on my system because it drops the -Wl, prefix that
>> gcc requires.  Using the system libtool (s#/bin/sh ./##) works
>> correctly. 
> 
> Which version of libtool is that?

2.2.6a, as stated above.

>> Changing to --tag=CXX and g++ without using system libtool
>> does not error, but libcgm.so.0.0.0 is not created (and is thus not
>> usable).
>>
> 
> This should not be necessary.  It is normal for libtool to use $CC when
> linking a library that is composed of other libraries and archives.

Yes, I was just observing that this changes where the build fails.  In
any case, it's incorrectly sending linker options without wrapping them
in -Wl, and (I think) we still need to use a C++ linker when linking a
shared library that depends on libstdc++ (or link it explicitly).

Jed


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mcs.anl.gov/pipermail/cgma-dev/attachments/20090918/bf63524e/attachment-0001.pgp>