Re: question about shared builds with Sun native compilers...

[Ed Hartnett]

"Dan Nicholson" <address@hidden> writes:

> On Tue, Apr 22, 2008 at 4:24 AM, Ed Hartnett <address@hidden> wrote:
>> Howdy all!
>>
>>  Firstly, thanks for developing libtool! It's really helpful!
>>
>>  I am using it to distribute a freeware scientific data library,
>>  netcdf. The netcdf distribution actually builds more than one
>>  library. It builds a core C library, and a fortran library. The
>>  fortran library calls the C library.
>>
>>  The way I handle this is to first build the fortran library, then the
>>  C library.
>
> Why not just build the C library first? That would seem to be not only
> logical, but preferable as the linker can actually analyze the symbols
> in the C library.

Howdy Dan!

I have a set of libraries: C, f77, f90, and C++. The user may build
any of all of these, depending on configure options. For historical
reasons the f77, f90 and C libraries may be built as one library. Each
API has it's own sub-directory.

Furthermore, there is a new sheriff in town, a new version of this
product which can optionally be built in addition to the existing
library. This new version of the C library exists in its own
sub-directory.

The end result of all this confusion is that I don't know which
sub-directory is going to have to produce a library, and which just a
convenience library, which will be used later to build the final
library.

There is, in addition to this, a required ordering of the directories
when building, which also has to be taken into account.

What I do is build my directories in this order, with some possibly
not built at all:

SUBDIRS = $(F90_DIR) $(F77_DIR) $(LIBSRC_DIR) \
$(DAPDIR) $(NCDAPDIR) $(LIBSRC4_DIR)    \
$(V2_TEST) $(NCGEN) $(NCDUMP) $(F77_TEST) ${CXX_DIR} $(CXX4)    \
$(NC_TEST_DIR) $(NC_TEST4) $(MAN) $(EXAMPLES) win32 

Sorry if I haven't made this very clear, but it's a complex situation!

>>  This works fine, except on my SunOS 5.8 sparc system, using SUNW
>>  compilers. In that case, it refuses to build the shared fortran
>>  library, complaining that the C library is not yet available:
>>
>>  libtool: compile:  cc -DHAVE_CONFIG_H -I. -I.. -I/include -I../libsrc4
>>  -I/upc/share/ed/local/buddy/include -g -c fort-nc4.c -o fort-nc4.o
>>  >/dev/null 2>&1
>>  /bin/bash ../libtool --tag=CC    --mode=link cc  -g
>>  -L/upc/share/ed/local/buddy/lib -version-info 5:0:0 -no-undefined  -o
>>  libnetcdff.la -rpath
>>  /buddy/netcdf/n4_buddy/netcdf-4.0-snapshot2008042120/install/lib
>>  fort-attio.lo fort-control.lo fort-dim.lo  fort-genatt.lo
>>  fort-geninq.lo fort-genvar.lo fort-lib.lo  fort-misc.lo
>>  fort-v2compat.lo fort-vario.lo fort-var1io.lo  fort-varaio.lo
>>  fort-varmio.lo fort-varsio.lo fort-nc4.lo ../f90/libnetcdff90.la
>>  -lsocket -lnsl
>>  libtool: link: cc -G -z defs -h libnetcdff.so.5 -o
>>  .libs/libnetcdff.so.5.0.0  .libs/fort-attio.o .libs/fort-control.o
>>  .libs/fort-dim.o .libs/fort-genatt.o .libs/fort-geninq.o
>>  .libs/fort-genvar.o .libs/fort-lib.o .libs/fort-misc.o
>>  .libs/fort-v2compat.o .libs/fort-vario.o .libs/fort-var1io.o
>>  .libs/fort-varaio.o .libs/fort-varmio.o .libs/fort-varsio.o
>>  .libs/fort-nc4.o  -z allextract ../f90/.libs/libnetcdff90.a -z
>>  defaultextract  -L/upc/share/ed/local/buddy/lib -lsocket -lnsl -lc
>>  Undefined                                                first
>>  referenced
>>   symbol                             in file
>>  nc_inq_att                          .libs/fort-genatt.o
>>  nc_inq_dim                          .libs/fort-dim.o
>>  nc_inq_var                          .libs/fort-genvar.o
>>  etc.
>>
>>  (The missing functions are from the C library.)
>>
>>  The shared build with gcc and gfortran works fine, as does the static
>>  build with the SUNW compilers.
>>
>>  Only the shared SUNW build is a problem.
>
> I would imagine there's a way to tell the SUNW linker to ignore
> undefined symbols. In fact, I think the errors are being forced by the
> "-z defs" option. I think this is being added because you're using the
> libtool flag "-no-undefined". That would seem to to be at odds with
> what you're trying to accomplish.


Yes, you are quite correct. That flag was meant to appear only on
MingW builds! Thanks for noticing! ;-)

I took out the -no-undefined and now it works a treat.

Thanks!

Ed

-- 
Ed Hartnett  -- address@hidden