Issue 11945

Summary: Provide linker mapfiles for dynamically loaded libraries
Product: porting Reporter: matthias.huetsch
Component: codeAssignee: matthias.huetsch
Status: CLOSED FIXED QA Contact: issues <>
Severity: trivial    
Priority: P3 CC: issues, khendricks
Version: 644   
Target Milestone: OOo 1.1 Beta2   
Hardware: All   
OS: All   
Issue Type: TASK Latest Confirmation on: ---
Developer Difficulty: ---
Issue Depends on: 11962, 11968, 12151, 12685, 12687, 12688, 12689, 12692, 12694    
Issue Blocks:    

Description matthias.huetsch 2003-03-01 16:37:51 UTC
By their very nature, all dynamically loaded libraries do have a well defined
exported API, and thus can always provide (symbol scoping) linker mapfiles (in
terms of GNU ld: --version-script).

Many dynamically loaded libraries do not yet provide such mapfiles, though they
often do provide a (windows only) .DEF file.

Meta 'porting' task to track issues against individual modules, upon which this
task will depend.
Comment 1 matthias.huetsch 2003-03-01 16:39:13 UTC
Accepting with tentative target 'OOo 1.1 Beta2'.
Comment 2 matthias.huetsch 2003-03-02 13:53:11 UTC
Added dependency to issue 11962.
Comment 3 matthias.huetsch 2003-03-02 19:48:21 UTC
Added dependency to issue 11968.
Comment 4 matthias.huetsch 2003-03-02 20:11:19 UTC
Linker mapfile (version script) for a dynamically loaded library
implementing a UNO component, e.g. called '':

UDK_3_0_0 {


In the corresponding '', all those fancy


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


The 'solenv' build environment takes care of the rest, i.e. feeds the
specified '' as mapfile (or version script) to a Unix 'ld'
or generates a Windows .DEF file and feeds that to a Windows linker.
Comment 5 khendricks 2003-03-06 21:53:23 UTC
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 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 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. 
Comment 6 matthias.huetsch 2003-03-06 22:23:24 UTC
Hi Kevin,

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

Seriously, what I meant 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/' 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 '' 
replacing all those '', '',
et al currently in use.

Hope that helps,

Comment 7 matthias.huetsch 2003-03-08 17:42:54 UTC
Added dependency to issue 12151.
Comment 8 matthias.huetsch 2003-04-11 20:13:31 UTC
With all dependencies resolved fixed, this is resolved fixed as well :-)
Comment 9 matthias.huetsch 2003-04-29 13:33:15 UTC
All dependencies verified and closed -> closing this as well.