Re: [libtool 2.2.11a] testsuite: 48 69 92 failed [cygwin]

[Charles Wilson]

On 6/17/2010 9:37 PM, Charles Wilson wrote:
> On 6/17/2010 9:14 PM, Charles Wilson wrote:
>> On 6/12/2010 4:58 AM, Ralf Wildenhues wrote:
>>> * Charles Wilson wrote on Fri, Jun 11, 2010 at 02:28:41PM CEST:
>>>> In 69, the library fails to open:
>>>
>>> No idea.  Maybe having the error reporting from libltdl fixed may help
>>> get a better clue here?
>>
>> What do you mean by this?  Are you referring to the problem Peter
>> O'Gorman's patch addresses?
>> http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00080.html
> 
> I guess not. With Peter's patch, I get the same error output as before:

During the ensuing discussion starting here:
http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00081.html
> Unfortunately, this doesn't magically assist solving my problem with
>    71. dlloader-api.at:23:  FAILED (dlloader-api.at:422)
> but that's not a reason to object to the patch.

and ending here:
http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00095.html
> However, the real issue isn't the exe magic, it's the fact that the test
> makes assumptions about what files ARE or ARE NOT in the
> LT_MODULE_PATH_VAR.  We *hope* that there is no "last" or "first" or
> "module" or "no_module" anywhere in there.
...
> However, if this IS the desired algorithm, then the "fix" is for our
> test to putenv (LT_MODULE_PATH_VAR, ""), right? And probably
> LTDL_SEARCHPATH_VAR, as well. But I'm not sure we can guarantee to "null
> out" sys_dlsearch_path at runtime; what if a file called "/usr/lib/last"
> exists, even on linux?

Peter's patch helped to localize and identify the issue.  The attached
fixes this regression on cygwin, but...I wonder if it is the Right Thing
To Do.  Comments?

--
Chuck

cygwin-dlloader-api-test.patch
Description: Source code patch