user_search_path vs libtool --mode=execute -dlopen

[Mark H Weaver]

Hello all,

I'm a Guile developer who is trying to figure out the best way to add a
Guile-specific 'extensions' directory to the library search path, while
retaining the ability of 'libtool --mode=execute -dlopen' to take
precedence over our default extensions directory.

As I understand it, on GNU systems 'libtool --mode=execute -dlopen' has
the effect of prepending a directory to $LD_LIBRARY_PATH.  It also
appears from the libltdl source code that the search order for
'lt_dlopenext' is as follows:

* user_search_path (augmented by 'lt_dladdsearchdir' et al)
* LTDL_LIBRARY_PATH
* LD_LIBRARY_PATH
* system default search path

I see only two ways to add our extensions directory to the search path,
such that it can be overridden by 'libtool --mode=execute -dlopen':

1. Append it to LD_LIBRARY_PATH.
2. Search in our extensions directory manually if 'lt_dlopenext' fails,
   by calling 'lt_dlopenext' a second time.

The problem with option 1 is that all subprocesses will inherit our
modified search path.  This could be a problem if there are two
different versions of Guile on the system, and one is used by a
subprocess of the other, because the sub-Guile will search in the
parent-Guile's extensions directory first.

Therefore, it seems that option 2 is the right thing, even though it is
quite kludgy.

I can't help but suspect that 'lt_dladdsearchdir' et al were intended
for programs to add their own system-wide extensions directory to the
search path.  Is that right?  If so, what's the recommended way to
override a program's default extensions directory?

Maybe the problem is that programs should not expect 'libtool
--mode=execute -dlopen' to override a program's extension directory.
However, it is being used this way in practice, for example by GNU TLS
(which provides a Guile extension) to ask that the uninstalled extension
in its build directory should take precedence over the one in the
system-wide Guile extensions directory.  See
.

I'm hoping that the libtool experts here can help me understand how this
is supposed to work.  I'm not subscribed to this list, so please CC
replies to me.

Thanks,
  Mark

___
https://lists.gnu.org/mailman/listinfo/libtool

Re: func_win32_import_lib_p when file is missing

[Peter Rosin]

On 2012-10-07 06:04, Gary V. Vaughan wrote:
> Hi Peter,
> 
> On 7 Oct 2012, at 06:53, Peter Rosin  wrote:
>> How is the below function supposed to work
>> when $file_magic_cmd is '$OBJDUMP -f' and not 'func_win32_libid'?
> 
> I have no idea :(
> 
>> objdump doesn't output "import" for me, at least not for any
>> import lib I have given it. Chunk?
>>
>> # func_win32_import_lib_p ARG
>> # True if ARG is an import lib, as indicated by $file_magic_cmd
>> func_win32_import_lib_p ()
>> {
>>$debug_cmd
>>
>>case `eval $file_magic_cmd \"\$1\" 2>/dev/null | $SED -e 10q` in
>>*import*) : ;;
>>*) false ;;
>>esac
>> }
> 
> Does '$OBJDUMP -f' output anything that can be used to distinguish an
> import library?

Don't think so.

> If so, add that to the *import* leg of the case statement above.  If not,

"objdump -f" output from normal static lib:
--8<---
In archive ../msvc/tests/testsuite.dir/035/.libs/hello.lib:

libhello_la-foo.obj: file format pe-i386
architecture: i386, flags 0x003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x

libhello_la-hello.obj: file format pe-i386
architecture: i386, flags 0x003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x
--8<---

And from an import lib:

--8<---
In archive ../msvc/tests/testsuite.dir/034/.libs/hello.dll.lib:

hello-2.dll: file format pe-i386
architecture: i386, flags 0x003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x

hello-2.dll: file format pe-i386
architecture: i386, flags 0x003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x

hello-2.dll: file format pe-i386
architecture: i386, flags 0x003d:
HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
start address 0x

hello-2.dll: file format pei-i386
architecture: i386, flags 0x0018:
HAS_DEBUG, HAS_SYMS
start address 0x

hello-2.dll: file format pei-i386
architecture: i386, flags 0x0018:
HAS_DEBUG, HAS_SYMS
start address 0x

hello-2.dll: file format pei-i386
architecture: i386, flags 0x0018:
HAS_DEBUG, HAS_SYMS
start address 0x
--8<---

I don't imagine any of the differences to be really useful. I don't
know though... pe-i386 vs. pei-i386 looks promising, but I don't
possess enough PE-COFF-fuu to tell for sure. I think it would
have been used previously if it really did work?

> then file_magic_cmd should not be set to '$OBJDUMP -f' for at least that
> particular combination of MSVC/objdump/mingw that you are using:

I don't think this is particular to my specific objdump, as it
is the one from GNU binutils, and I believe this problem with
func_win32_import_lib_p to be generic to all known objdumps out
there. I don't think this has ever worked as intended.

>> mingw* | pw32*)
>>  # Base MSYS/MinGW do not provide the 'file' command needed by
>>  # func_win32_libid shell function, so use a weaker test based on 'objdump',
>>  # unless we find 'file', for example because we are cross-compiling.
>>  # func_win32_libid assumes BSD nm, so disallow it if using MS dumpbin.
>>  if ( test "$lt_cv_nm_interface" = "BSD nm" && file / ) >/dev/null 2>&1; then
>>lt_cv_deplibs_check_method='file_magic ^x86 archive import|^x86 DLL'
>>lt_cv_file_magic_cmd='func_win32_libid'
>>  else
>># Keep this pattern in sync with the one in func_win32_libid.
>>lt_cv_deplibs_check_method='file_magic file format 
>> (pei*-i386(.*architecture: i386)?|pe-arm-wince|pe-x86-64)'
>>lt_cv_file_magic_cmd='$OBJDUMP -f'
> 
>  lt_cv_file_magic_cmd='func_win32_libid'
> 
> ??

func_win32_libid requires file(1) to be present (wasn't always the
case on MSYS) and that "$NM -f posix -A " is useful (obviously
not the case when NM="dumpbin -symbols").

I suppose one way forward is to flesh out func_win32_libid to also
handle $lt_cv_nm_interface = "MS dumpbin" and then rely on file to
be present. That would make MSVC work on modern but not legacy
MSYS, which does not seem like much of an issue. But that would not
solve matters for wince and old MSYS lacking file(1), and any solution
for those would perhaps be a solution for NM="dumpbin -symbols" as
well, and piggybacking like that is always nice.

Cheers,
Peter


___
https://lists.gnu.org/mailman/listinfo/libtool

Re: func_win32_import_lib_p when file is missing

[Gary V. Vaughan]

Hi Peter,

On Oct 7, 2012, at 4:37 PM, Peter Rosin  wrote:
> On 2012-10-07 06:04, Gary V. Vaughan wrote:
>> On 7 Oct 2012, at 06:53, Peter Rosin  wrote:
>>> objdump doesn't output "import" for me, at least not for any
>>> import lib I have given it. Chunk?
>>> 
>>> # func_win32_import_lib_p ARG
>>> # True if ARG is an import lib, as indicated by $file_magic_cmd
>>> func_win32_import_lib_p ()
>>> {
>>>   $debug_cmd
>>> 
>>>   case `eval $file_magic_cmd \"\$1\" 2>/dev/null | $SED -e 10q` in
>>>   *import*) : ;;
>>>   *) false ;;
>>>   esac
>>> }
>> 
>> Does '$OBJDUMP -f' output anything that can be used to distinguish an
>> import library?
> 
> "objdump -f" output from normal static lib:
> --8<---
> In archive ../msvc/tests/testsuite.dir/035/.libs/hello.lib:
> 
> libhello_la-foo.obj: file format pe-i386
> architecture: i386, flags 0x003d:
> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
> start address 0x
> 
> libhello_la-hello.obj: file format pe-i386
> architecture: i386, flags 0x003d:
> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
> start address 0x
> --8<---
> 
> And from an import lib:
> 
> --8<---
> In archive ../msvc/tests/testsuite.dir/034/.libs/hello.dll.lib:
> 
> hello-2.dll: file format pe-i386
> architecture: i386, flags 0x003d:
> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
> start address 0x
> 
> hello-2.dll: file format pe-i386
> architecture: i386, flags 0x003d:
> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
> start address 0x
> 
> hello-2.dll: file format pe-i386
> architecture: i386, flags 0x003d:
> HAS_RELOC, HAS_LINENO, HAS_DEBUG, HAS_SYMS, HAS_LOCALS
> start address 0x
> 
> hello-2.dll: file format pei-i386
> architecture: i386, flags 0x0018:
> HAS_DEBUG, HAS_SYMS
> start address 0x
> 
> hello-2.dll: file format pei-i386
> architecture: i386, flags 0x0018:
> HAS_DEBUG, HAS_SYMS
> start address 0x
> 
> hello-2.dll: file format pei-i386
> architecture: i386, flags 0x0018:
> HAS_DEBUG, HAS_SYMS
> start address 0x
> --8<---
> 
> I don't imagine any of the differences to be really useful. I don't
> know though... pe-i386 vs. pei-i386 looks promising, but I don't
> possess enough PE-COFF-fuu to tell for sure. I think it would
> have been used previously if it really did work?

Am I crazy, or isn't it a matter of file naming conventions here?

If all import libs are named foo.dll.lib, and regular dlls are named foo.dll,
then it's easy to write a case statement to distinguish the two :)

That sounds too simple to be true though, so what about testing for the
property that the import library has a bunch of references to a dll matching:

  /^[^:]*\.dll:/

Where the static library has a bunch of references to object files matching:

  /^[^:]*\.(o|lo|obj):/

??

Are either of those a step in the right direction?

Cheers,
-- 
Gary V. Vaughan (gary AT gnu DOT org)

___
https://lists.gnu.org/mailman/listinfo/libtool