Apache OpenOffice (AOO) Bugzilla – Issue 80735
cppu: make the gcc3 map generic for 64bit as well
Last modified: 2007-11-16 15:34:41 UTC
i.e. on my ppc64 build I got _ZN4cppu6helper7purpenv13createMappingEPP12_uno_MappingP16_uno_EnvironmentS6_PFvbPvS7_P33_typelib_TypeDescriptionReferenceP24_typelib_MethodParameteriPK24_typelib_TypeDescriptionS7_PS7_PP8_uno_AnyES7_ which the x86_64,map has, but sounds better to wildcard the i/l with ? and merge the x86_64 and 32bit ones into one that works for all gcc's including the ppc64 port
Created attachment 47572 [details] merge 32bit and 64bit maps
I'll look after this after I confirm that ppc64/ppc/x86_64/i386 all build and work.
+ me on CC
Works for me in i386/x86_64/ppc/ppc64. cmc->vq: Does the cygwin/mygwin windows gcc port really need a different .map file or would the proposed map file attached below be sufficient so as to merge all the gcc .map files together
> cmc->vq: Does the cygwin/mygwin windows gcc port really need a different .map > file or would the proposed map file attached below be sufficient so as to merge > all the gcc .map files together @cmc: I don't know, but tono does. I added him to the cc list.
cmc: Mingw port is handling version map file to export symbols by converting it to .def file as MSVC build does. So the version map file cannot include wild-card characters in its symbol expressions although the mangled names are very similar to those in version map files for other gcc platforms. tono (Takashi Ono)
@tono: Would it be OK for the generated def file to contain extra symbol names that are not present in the object? If yes, we could devise some scheme by which we expand wildcards in the generic map file into multiple entries in the generated def file, of which one would represent an actual symbol and the others would be ignored.
AFAIK, we are doing what SB suggested for Mac OS X as well, if I remember correctly Tino did implement this -> adding Tino to CC:.
@kr: No, for Mac OS X we deliberately introduce wildcards into the map files so that the linker does not complain about missing symbols. See for example jvmaccess/util/gcc3_linux_intel.map:1.14 l. 64--66: "We prefix the next two symbols with a wildcard sign because they will only be generated by gcj. The Mac OS X linker doesn't support 'Treat not existing symbols as warning' under certain circumstances and thus ends with an error when trying to find these symbols (see man ld on Mac OS X). For further details see also #i69351#. By using the wildcard the symbols will be filtered out before."
->SB: Not sure if I understand you correctly. The Mac OS X mechanism does a "nm" on all *.o and basically filters these against the appropriate map file using awk, actually achieving an "expansion" of the wildcards against the available symbols ... Thought the same was wished for mingw.
@sb and all: Cuurently mingw port is handling version map just in the same way as MSVC build. So the extra symbol in version map will generate extra symbol in .def and cause linkage error. However, it is possible to introduce conditional make in tg_def.mk to hadle mingw case differently and use nm and awk although it may be a bit slower. I will try to implement it but until then, mingw have to have dedicated version map. tono (Takashi Ono)
->Tono: Do you think it would be possible to re-use the Mac OS X stuff? Though not too pretty :-) it is actually there and works reasonably well ...
Does someone from udk want to take this task over, given that the cygwin stuff complicates what I originally saw as a simple tweak ?
k, I've merged them in cmcfixes38. I left the cygwin situation unaffected with a un-wildcarded version and the other gcc platforms use a common map.
cmc->kr: for verification in cmcfixes38
->Caolan: Please give me two weeks. I am currently away and going on vacation afterwards ... ;-)
Looks good so far :-)
seen in SRC680_m237