bug-libtool
[Top][All Lists]
Advanced

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

Re: dlpreopening for windows hosts and name of the module


From: Peter Rosin
Subject: Re: dlpreopening for windows hosts and name of the module
Date: Mon, 27 Sep 2010 09:12:05 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2

Den 2010-09-26 20:58 skrev Roumen Petrov:
> Hello all,
> 
> The libtool manual describe dlpreopening and details structure of 
> preloaded_symbols.
> 
> The current test "enforced lib prefix"(need_lib_prefix.at) pass on windows
> host as modules are build without -no-undefined flag.
> 
> If the test is modified as -no-undefined is add to build libtool create
> following list with symbols:
> lt__PROGRAM__LTX_preloaded_symbols[] =
> {  { "@PROGRAM@", (void *) 0 },
>   {"libfoo1.dll", (void *) 0},
>   {"libfoo1_LTX_i", (void *) &foo1_LTX_i},
>   {"libfoo1_LTX_f", (void *) &foo1_LTX_f},
>   {"libfoo2.dll", (void *) 0},
>   {"libfoo2_LTX_i", (void *) &libfoo2_LTX_i},
>   {"libfoo2_LTX_f", (void *) &libfoo2_LTX_f},
>   {0, (void *) 0}
> };
> 
> In this case the test will fail
> "84. need_lib_prefix.at:25:  skipped (need_lib_prefix.at:170)"
> with following message on standart error:
> function `f' not found: Procedure not found
> error during preloading.
> 
> 
> The issue is that preopen interface search for modules ending only with
> suffix ".a" but libtool func_generate_dlsyms set as name of module the
> name of dll.

Your patch seems like a sure way to make it break for MSVC where the
suffix is not ".a".  To me, the correct change seems to be to make the
preopen interface search more flexible. Or, if it is totally invalid to
put stuff with a ".dll" suffix where the preopen interface search only
looks for ".a", then fix that instead.

If this test requires *any* code change to make it pass, then that code
change is suspect.  If you think you have found a problem exposed by
this test, you should first check if the problem is real by doing the
same thing the test is doing but without the doctored libtool script
(possibly on one of the systems the test is designed to emulate).  Only
then can you be certain that it isn't the edited libtool script that is
the cause of the problem in the first place.  In this case it might be
a real problem (it probably is), but you need to show that first.  If
you do find a real problem, please copy this test, then change the copy
so that it does not use a locally modified libtool script.

Cheers,
Peter



reply via email to

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