Den 2010-09-24 07:15 skrev Ralf Wildenhues: > Hi Peter, > > * Peter Rosin wrote on Fri, Sep 24, 2010 at 12:39:13AM CEST: >> With the patch posted with subject: [PATCH] tests: import variables for MSVC. >> I found that libtool tries to put some bad symbols in the generated >> symbol lookup table leading to errors such as this: > >> Ok to push? > > Yes, with nit below addressed.
Thanks for the review! Pushed with nits. >> Subject: [PATCH] msvc: don't try to export import descriptors. >> >> * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin, mingw] >> [pw32, cegcc] <cl*, exclude_expsyms>: Don't export symbols in >> import libraries related to describing what dll(s) the import >> library is importing. Fixes problem in tests/demo-make.test >> and some other tests. > >> --- a/libltdl/m4/libtool.m4 >> +++ b/libltdl/m4/libtool.m4 >> @@ -4492,7 +4492,9 @@ m4_if([$1], [CXX], [ >> ;; >> cygwin* | mingw* | cegcc*) >> case $cc_basename in >> - cl*) ;; >> + cl*) >> + _LT_TAGVAR(exclude_expsyms, >> $1)=['_GLOBAL_OFFSET_TABLE_|_GLOBAL__F[ID]_.*|_NULL_IMPORT_DESCRIPTOR|_IMPORT_DESCRIPTOR_.*'] > > Does cl generate _GLOBAL_OFFSET_TABLE_ symbols, or _GLOBAL__F* ones? No, not that I know of. > If yes, is the leading underscore for the former optional? > > I'm guessing "no" for both of these, which means you can omit them here. Ok, I'll zap them. If this is the wrong decision I guess we'll find out. > I'm also guessing that GCC won't generate them either on w32, but really > not so sure about that; and the MSVC case is easier because we don't risk > regressions in leaving them out for now. Cheers, Peter
