[Top][All Lists]

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


From: Ralf Wildenhues
Date: Fri, 17 Sep 2010 21:14:29 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

Hi Peter,

* 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
> 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.

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.


diff --git a/libltdl/ltdl.h b/libltdl/ltdl.h
index 5154da1..31cbc5f 100644
--- a/libltdl/ltdl.h
+++ b/libltdl/ltdl.h
@@ -101,6 +101,9 @@ LT_SCOPE int        lt_dlpreload_default (const 
lt_dlsymlist *preloaded);
 LT_SCOPE int   lt_dlpreload_open    (const char *originator,
                                      lt_dlpreload_callback_func *func);
+/* Ensure C linkage.  */
+extern LT_DLSYM_CONST lt_dlsymlist lt__PROGRAM__LTX_preloaded_symbols[];
 #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[];      \

reply via email to

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