libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Which libtool for autoconf 2.54?


From: John Gruenenfelder
Subject: Which libtool for autoconf 2.54?
Date: Thu, 10 Oct 2002 13:53:44 -0700
User-agent: Mutt/1.4i

I'm using autoconf 2.54 and automake 1.7 (same results with 1.6 too).  Which
version of libtool *should* I be using?

I've tried several.  When I use the version of 1.4.2 that comes in Debian Sid
(1.4.2-7.1), I get the following problem at the final linking of my binary:

/bin/sh ../libtool --mode=link gcc -DCOMPDATE="\"`date`\"" \
-DMOD_PATH="\"/net/bach/home/johng/progs/c/opc/opc2/inst_opc/lib/opc\"" -g \
-O2 -o opc -export-dynamic opc_parser.o opc_lexer.o opc_main.o opc_execute.o \
opc_util.o opc_nodes.o opc_lists.o opc_nodemath.o opc_module.o opc_input.o \
opc_builtin.o opc_parseopts.o opc_script.o opc_hash.o -dlopen \
../modules/opc_math.la -dlopen ../modules/opc_fileio.la -dlopen \
../modules/opc_imgen.la -dlopen ../modules/opc_immath.la -dlopen \
../modules/opc_imwrap.la -dlopen ../modules/opc_header.la \
../replace/libreplace.la ../libopcutil/libopcutil.la ../libltdl/libltdlc.la \
../libim/libim.la ../libhlist/libhlist.la ../libcmplx/libcmplx.la -lreadline \
-lfl ../libltdl/libltdlc.la -ldmalloc
libtool: link: warning: `AC_LIBTOOL_DLOPEN' not used. Assuming no dlopen \
support. 
rm -f .libs/opc.nm .libs/opc.nmS .libs/opc.nmT
creating .libs/opcS.c
extracting global C symbols from `../modules/.libs/opc_math.so'
extracting global C symbols from `../modules/.libs/opc_fileio.so'
extracting global C symbols from `../modules/.libs/opc_imgen.so'
extracting global C symbols from `../modules/.libs/opc_immath.so'
extracting global C symbols from `../modules/.libs/opc_imwrap.so'
extracting global C symbols from `../modules/.libs/opc_header.so'
(cd .libs && gcc -c -fno-builtin -fno-rtti -fno-exceptions "opcS.c")
rm -f .libs/opcS.c .libs/opc.nm .libs/opc.nmS .libs/opc.nmT
gcc "-DCOMPDATE=\"Wed Oct  9 18:38:10 MST 2002\"" \
-DMOD_PATH=\"/net/bach/home/johng/progs/c/opc/opc2/inst_opc/lib/opc\" -g -O2 \
-o .libs/opc opc_parser.o opc_lexer.o opc_main.o opc_execute.o opc_util.o \
opc_nodes.o opc_lists.o opc_nodemath.o opc_module.o opc_input.o opc_builtin.o \
opc_parseopts.o opc_script.o opc_hash.o .libs/opcS.o -Wl,--export-dynamic \
../modules/.libs/opc_math.so ../modules/.libs/opc_fileio.so \
../modules/.libs/opc_imgen.so ../modules/.libs/opc_immath.so \
../modules/.libs/opc_imwrap.so ../modules/.libs/opc_header.so \
../replace/.libs/libreplace.al ../libopcutil/.libs/libopcutil.al \
../libim/.libs/libim.so -lm ../libhlist/.libs/libhlist.so \
../libcmplx/.libs/libcmplx.so -lreadline -lfl ../libltdl/.libs/libltdlc.al \
-ldl -ldmalloc -Wl,--rpath \
-Wl,/net/bach/home/johng/progs/c/opc/opc2/inst_opc/lib/opc -Wl,--rpath \
-Wl,/net/bach/home/johng/progs/c/opc/opc2/inst_opc/lib
creating opc

The important line appears to be:
libtool: link: warning: `AC_LIBTOOL_DLOPEN' not used. Assuming no dlopen \
support.

I don't know why this is generated, since I am calling that macro in my
configure.ac.  When I install and run the compiled binary, I get a number of
errors when the modules are loaded at startup:

Error getting module_definition from module 'opc_fileio':
        unknown error

'module_definition' is a symbol in each of my modules.  It is defined using
the normal libtool syntax of opc_fileio_LTX_module_definition.  Checking the
module with nm, I can see the symbol in the file.  The second line above,
"unknown error", is the string returned by lt_dlerror().  Not that helpful.
Needless to say, my program isn't very useful in this state.

Another problem I have with the 1.4.2 version of libtool happens if I set the
CC and CFLAGS environment variables.  If I set those, my configure script will
correctly use them, but I get errors when the configure script in the libltdl
directory is run.  They are passed as arguments to libltdl's configure as
'CC=foo' 'CFLAGS=foo'.  The configure script interprets these as the host type
I want to compile for, which is obviously not the correct thing to do.  I get
around this bug by simply not setting those variables.  Of course, then I
can't use gcc-3.2.

Next, I tried the HEAD branch of libtool CVS, current as of Oct. 9.  I get the
same error as with 1.4.2.  That is, I get the runtime "unknown error"
messages.  I do not, however, get the AC_LIBTOOL_DLOPEN warning from libtool,
and I can also set CC/CFLAGS without problems.

The code in question is actually very short:

  /* Open the module */
  libhandle = lt_dlopenext(modfile);
  if (!libhandle)
    {
      err_error("Error opening function module: %s\n%s\n",
                modfile, lt_dlerror());
      return FALSE;
    }

  /* Get the module definition information from the module */
  moddef = (const char **)lt_dlsym(libhandle, "module_definition");
  error = lt_dlerror();
  if (error != NULL)
    {
      err_error("Error getting module_definition from module '%s':\n",
                modfile);
      err_error("\t%s\n", error);
      lt_dlclose(libhandle);
      return FALSE;
    }


The relevant portion of my configure.ac is (I think):

AC_LIBLTDL_CONVENIENCE
AC_LIBTOOL_DLOPEN
AM_PROG_LIBTOOL
AC_LIB_LTDL

AC_SUBST(LIBTOOL_DEPS)
AC_SUBST(LTDLINCL)
AC_SUBST(LIBLTDL)

AC_CONFIG_SUBDIRS(libltdl)


Do I have those in the proper order?  I *can* get my program
working... mostly.  I have a CVS version of libtool from around April that
I've also tried.  With that version, I get the same libtool warning that 1.4.2
generates, but the program seems to work properly.  What am I doing wrong?
Let me know if there is any additional information I can give.


-- 
--John Gruenenfelder    Research Assistant, Steward Observatory, U of Arizona
address@hidden
"This is the most fun I've had without being drenched in the blood
of my enemies!"
        --Sam of Sam & Max

Attachment: pgpwWgYCiydjX.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]