Re: fixing linkage against uninstalled libtool archives on macos?

[Ralf Wildenhues]

* Andy Wingo wrote on Mon, Nov 17, 2008 at 11:39:01AM CET:
> On Thu 13 Nov 2008 21:46, Ralf Wildenhues <address@hidden> writes:
> > What I don't understand is: your --config output had
> > | hardcode_direct=no
> >
> > so something set this to "yes" in the meantime.  That bit is wrong.
> > Any chance the package you are building is using a patched ltmain.sh
> > file?
> 
> I don't think anything is patching ltmain.sh, no. And while I'm pretty
> sure that I did invoked ./libtool --config correctly before, now it's
> giving me different results -- I must have done something to it in the
> meantime (but I really don't know what), or invoked it incorrectly.
> (This bug still manifests itself in the same way though.) Attaching the
> --config log.

Let's take a look at the differences of the two --config outputs:


| +# Assembler program.
| +AS=as
|  
| +# DLL creation program.
| +DLLTOOL=dlltool
|  
| -$ ./libtool --config
| +# Object dumper program.
| +OBJDUMP=objdump

So one of them used win32-dll (aka AC_LIBTOOL_WIN32_DLL), while the
other did not.

| @@ -115,7 +16,7 @@
|  build_libtool_libs=yes
|  
|  # Whether or not to build static libraries.
| -build_old_libs=yes
| +build_old_libs=no

Huh?  Did you rerun configure with --disable-static?

| @@ -176,9 +77,6 @@
|  reload_flag=" -r"
|  reload_cmds="\$LTCC \$LTCFLAGS -nostdlib \${wl}-r -o \$output\$reload_objs"
|  
| -# An object symbol dumper.
| -OBJDUMP="false"
| -

See above.

| @@ -201,7 +99,7 @@
|  LTCC="gcc"
|  
|  # LTCC compiler flags.
| -LTCFLAGS="-I/opt/yobuild/include -g -O0"
| +LTCFLAGS="-I/opt/yobuild/include  -O -g -gstabs+3 -std=gnu89"

Did you reconfigure with different CFLAGS set?

| @@ -303,10 +201,10 @@
|  hardcode_into_libs=no
|  
|  # Compile-time system search path for libraries.
| -sys_lib_search_path_spec="/usr/lib/i686-apple-darwin9/4.0.1 /usr/lib 
/usr/lib/gcc/i686-apple-darwin9/4.0.1 /usr/local/lib"
| +sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib"
|  
|  # Run-time system search path for libraries.
| -sys_lib_dlsearch_path_spec="/usr/local/lib /lib /usr/lib"
| +sys_lib_dlsearch_path_spec="/lib /usr/lib"

Hmm.

| @@ -401,7 +299,7 @@
|  
|  # Set to "yes" if using DIR/libNAME${shared_ext} during linking hardcodes
|  # DIR into the resulting binary.
| -hardcode_direct=no
| +hardcode_direct=yes

Hmm.

| @@ -453,24 +351,3 @@
|  # How to hardcode a shared library path into an executable.
|  hardcode_action=immediate
|  
| -# The directories searched by this compiler when creating a shared library.
| -compiler_lib_search_dirs=""
| -
| -# Dependencies to place before and after the objects being linked to
| -# create a shared library.
| -predep_objects=""
| -postdep_objects=""
| -predeps=""
| -postdeps=""
| -
| -# The library search path used internally by the compiler when linking
| -# a shared library.
| -compiler_lib_search_path=""

Hmm.

Doesn't ring an obvious bell yet.  Can you try to configure and make
this package anew, in a clean build directory tree?

Thanks,
Ralf