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: Sat, 18 Sep 2010 11:45:55 +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-17 21:14 skrev Ralf Wildenhues:
> * Peter Rosin wrote on Fri, Sep 17, 2010 at 04:22:37PM CEST:
>> I have been trying to fix exceptions.at on MSVC and have stumbled
>> into a problem. The function main() in main.cpp starts out with
>> LTDL_SET_PRELOADED_SYMBOLS();
>>
>> If you look at what that macro does, it look like this in ltdl.h:
>>
>> #define lt_preloaded_symbols lt__PROGRAM__LTX_preloaded_symbols
>> #define LTDL_SET_PRELOADED_SYMBOLS()                         LT_STMT_START{  
>> \
>>      extern LT_DLSYM_CONST lt_dlsymlist lt_preloaded_symbols[];      \
>>      lt_dlpreload_default(lt_preloaded_symbols);                     \
>>                                                      }LT_STMT_END
>>
>> I.e. call lt_dlpreload_default with the address of
>> lt__PROGRAM__LTX_preloaded_symbols as argument. Now, that address
>> comes from the generated symbol resolution table, i.e. main.exeS.c
>> in this case. The code from that file looks like this if you cut
>> out the "crap":
>>
>> #ifdef __cplusplus
>> extern "C" {
>> #endif
>>
>> typedef struct {
>>   const char *name;
>>   void *address;
>> } lt_dlsymlist;
>> extern lt_dlsymlist
>> lt__PROGRAM__LTX_preloaded_symbols[];
>> lt_dlsymlist
>> lt__PROGRAM__LTX_preloaded_symbols[] =
>> {  { "@PROGRAM@", (void *) 0 },
>>   {0, (void *) 0}
>> };
>>
>> #ifdef __cplusplus
>> }
>> #endif
>>
>> See the mismatch? main.cpp gets lt__PROGRAM__LTX_preloaded_symbols with
>> C++ linkage, and main.exeS.c gets it with C linkage. So, linking main.exe
>> explodes with:
> 
> Hmpf.  That sucks rocks.  Darn, I didn't know C++ compilers could mangle
> variable types.  Now I need to look at v2.2.10-126-g5b79e16 again to
> check whether it caused ABI breakage ...
> 
>> Should I do extern "C" { ... } around the whole main() function in main.cpp
>> or what? (that makes it build, when some other nits have been fixed)
> 
> No, that's not right; main needs to have C++ linkage.  I still haven't
> read up completely on the linkage spec issue yet, but so far I
> understood that:
> 
> - C++ linkage specs must be at namespace scope, so we can't stick it
> inside the LTDL_SET_PRELOADED_SYMBOLS macro.  :-/
> 
> - Even with a typedef of a struct inside `extern "C"' namespace scope
> (in this case, lt_dlsymlist defined in ltdl.h), MSVC still seems to
> mangle the name of an array of such a type.
> 
> 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.

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.

Cheers,
Peter



reply via email to

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