Re: Re: Building OpenOffice.org with GNU make

Jussi Pakkanen wrote:
> On Thu, Feb 11, 2010 at 2:01 PM, Martin Hollmichel
> <[email protected]> wrote:
>
>   
>>>> one problem right now is that the usage of linker mapfiles (e.g.
>>>> sal/util/sal.map) are not straight supported by cmake, unfortunately all
>>>> the
>>>> creation of several win32 import libraries are dependent to such
>>>> mechanism,
>>>> only some of the OOo Libs support the declspec(dllexport) or the Unix
>>>> visibility mechanisms. so here some work is required.
>>>>         
>>> I'll try to look into this.
>>>
>>>       
>> thanks,
>>     
>
> I looked into it and got lost in a twisty passage of makefiles, Perl
> scripts and lib/a/so files. Could someone give a brief description on
> how the system works. Specifically how the different files are
> processed and what is finally passed to the linker.
>   
usually I analyse the build logs for understanding these kind of 
mechanisms, here's my extract for sal module on Linux:
...
tr -d "\015" < sal.map | awk -f ...../solenv/bin/addsym.awk > 
../unxlngi6.pro/misc/sal_uno_sal.map
....
Making: ../unxlngi6.pro/lib/libuno_sal.so.3
g++ -Wl,-z,noexecstack -Wl,-z,combreloc -Wl,-z,defs 
-Wl,-Bsymbolic-functions -Wl,--dynamic-list-cpp-new 
-Wl,--dynamic-list-cpp-typeinfo -Wl,--hash-style=both 
-Wl,-rpath,'$ORIGIN' "-Wl,-hlibuno_sal.so.3" -shared -Wl,-O1 
-Wl,--version-script ../unxlngi6.pro/misc/sal_uno_sal.map .......
> Another question is whether the map files currently solve any problem
> that cannot be dealt with native symbol visibility settings?
>   
as the linker script above shows, the option "-version script" is used, 
the reason for this is explained in the ld man page:
"Specify the name of a version script to the linker.  This is typically 
used when creating shared libraries to specifc additional information 
about the version hierarchy for the library being created.  This option 
is only fully supported on platforms which support shared libraries; see 
VERSION.  It is partially supported on PE platforms, which can use  
version scripts to filter symbol visibility in auto-export mode: any 
symbols marked local in the version script will not be exported."

e.g. an exerpt from the sal-map file:

"...
UDK_3.7 { # OOo 2.4
    global:
        osl_loadModuleRelative;
} UDK_3.6;

UDK_3.8 { # OOo 3.0
    global:
        rtl_bootstrap_encode;
        rtl_convertStringToUString;
        rtl_math_approxValue;
} UDK_3.7;

UDK_3.9 { # OOo 3.1
    global:
        osl_mapFile;
        osl_unmapFile;

        osl_readFileAt;
        osl_writeFileAt;

        rtl_math_expm1;
        rtl_math_log1p;
        rtl_math_atanh;
} UDK_3.8;

UDK_3.10 { # OOo 3.2
    global:
        rtl_logfile_hasLogFile;
        rtl_math_erf;
        rtl_math_erfc;
        rtl_math_asinh;
        rtl_math_acosh;
} UDK_3.9;"


But you're also right, there are also still libraries around where the 
native symbol visibilty could (and IMHO should) be used, but this would 
require quite a lot manual code changes (many already have been done, 
but not all yet),

hth,

Martin