"Dan Nicholson" <[EMAIL PROTECTED]> writes:
> On Tue, Apr 22, 2008 at 4:24 AM, Ed Hartnett <[EMAIL PROTECTED]> 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 -- [EMAIL PROTECTED]
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
