Issue 11945

Accepting with tentative target 'OOo 1.1 Beta2'.

Added dependency to issue 11962.

Added dependency to issue 11968.

Linker mapfile (version script) for a dynamically loaded library
implementing a UNO component, e.g. called 'exports.map':

UDK_3_0_0 {
        global:
                GetVersionInfo;
                component_getDescriptionFunc;
                component_getImplementationEnvironment;
                component_getFactory;
                component_writeInfo;

        local:
                *;
};

In the corresponding 'makefile.mk', all those fancy

USE_DEFFILE=TRUE
USE_LDUMP2=TRUE

lines should be removed, and be replaced by instructions like:

SHL1TARGET= $(TARGET)
SHL1IMPLIB= i$(TARGET)

SHL1VERSIONMAP=exports.map
SHL1DEF=$(MISC)$/$(SHL1TARGET).def
DEF1NAME=$(SHL1TARGET)

The 'solenv' build environment takes care of the rest, i.e. feeds the
specified 'exports.map' as mapfile (or version script) to a Unix 'ld'
or generates a Windows .DEF file and feeds that to a Windows linker.

Hi,  (Adding myself to CC on this one). 
 
I do not know alot about map files in general so I have one related question?  
 
Must the Linux map files be cpu specific or can they be generalized to all Linux platforms? 
 
Specifically, can we make all Linux_intel.map files generic so that they work for x86, ppc, 
and s390 (our currently working linux ports)?   
 
My guess is they should work for PPC Linux and S390 Linux as well since we all use the 
same compiler and have the same entry points (almost nothing but the bridge code and 
the atomic increment/derement code are ppc linux specific) and even those entry points 
would be identical in symbol names correct? 
 
If the answer to this is uncertain I would be happy to test any and all Linux_intel.map files 
on my PPC Linux build and attempt to identify if any irregularities exists.  Basically I could 
use nm or readelf and grep to make sure the all of the symbols in the Linux_intel map files 
are present in the PPC Linux version of the library. 
 
Any guidance about their reusability would be appreciated. 
 
Thanks, 
 
Kevin 
 
 
 

Hi Kevin,

Somehow I knew you would stumble over this issue :-)

Seriously, what I meant by '...by their very nature...' is that all
dynamically loaded -- dlopen()'ed -- libraries do export a C API, only.

There is no C++ name mangling involved at all, and thus these version
scripts (or map files) are neither CPU nor OS dependent, provided the
used linker on a particular OS does support this concept at all (or
some kind of script applies a translation into something similar, as
is done on Windows to generate a .DEF file from the map file).

As the GNU ld supports this via the '-version-script' switch, all
GNU binutils based OSes (in particular all Linux platforms) can make
use of this mechanism.
In case that 'solenv/inc/unxlngppc.mk' is your's then it's already
enabled (grep for VERSIONMAP -> LINKVERSIONMAPFLAG=...).

Just to clarify, this issue applies to *dynamically* loaded libs with
C exports, only. Libraries with C++ exports are not yet addressed 
here. I'm still thinking about a practical solution, but you're on
the right track in that even those map files can most probably be
simplified to depend on the *compiler* only (i.e. a 'gcc3.map' 
replacing all those 'linux_intel_gcc3.map', 'freebsd_alpha_gcc3.map',
et al currently in use.

Hope that helps,
Matthias

Added dependency to issue 12151.

With all dependencies resolved fixed, this is resolved fixed as well :-)

All dependencies verified and closed -> closing this as well.