bug-libtool
[Top][All Lists]
Advanced

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

Re: Linkage and LTDL_SET_PRELOADED_SYMBOLS


From: Peter Rosin
Subject: Re: Linkage and LTDL_SET_PRELOADED_SYMBOLS
Date: Mon, 20 Sep 2010 10:33:15 +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

Hi Ralf,

Den 2010-09-18 11:45 skrev Peter Rosin:
> Den 2010-09-17 21:14 skrev Ralf Wildenhues:
>> As a workaround, does it work to put a declaration of the program
>> symlist in ltdl.h as below?  You might have to remove the corresponding
>> declaration from the LTDL_SET_PRELOADED_SYMBOLS macro in that case, to
>> avoid incompatible redeclaration.
> 
> Doing that makes main.exe link, just as if I do main() with C linkage as
> I asked. The test still doesn't pass though. I get this output (same result
> as with main() with C linkage):
> 
> $ ./main -dlopen m/module.la
> exceptions_in_prog
> caught: exception in program
> exceptions_in_lib
> caught inside lib: exception in library
> caught: exception from library
> exceptions_in_module
> dlopen failed: file not found
> 
> I haven't looked into that failure yet, but suspect that it is some
> PATH issue or posix vs. windows abs dir thing which is unrelated to
> this. I will not look at this until after the weekend.

Now I have, and that failure was of the PEBCAK type. The test passes
with the two patches in the followup mails. Testsuite is running on
MinGW and Cygwin (gcc) and have completed enough of it that I don't
think there will be any regressions.

> BTW, I didn't need to change the define, perhaps since the two
> declarations refer to different symbols on MSVC. I assume other
> compilers will complain though.
> 
>> For configure CC=<some-C++-compiler>, probably tests/demo/dlmain.c
>> and tests/pdemo/longer_file_name_dlmain.c would need fixing, too.
>>
>> I haven't checked yet whether any of the other symlist instances (where
>> the part before _LTX_preloaded_symbols is not equal to _PROGRAM_) need
>> fixing, too.
> 
> Me neither. BTW, getting MSVC++ correct is not a release blocker from
> my point of view.

Still true.  The two patches can wait until after the release if they
are deemed too wild.

Cheers,
Peter



reply via email to

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