Thanks Rod. Please see my comments below.
Rod Evans wrote:
> brian.lu wrote:
>> Hi, experts,
>>
>> When I build a shared library libmork.so ( a Firefox component) with
>> following command:
>> .....
>> I got following warning message:
>>
>> Undefined first
>> referenced
>> symbol in file
>> NSRegisterSelf
>> /export/home/brian/moz-ws/community2/builds/build1101/mozilla/build/unix/gnu-ld-scripts/components-mapfile
>>
>>
>> NSGetFactory
>> /export/home/brian/moz-ws/community2/builds/build1101/mozilla/build/unix/gnu-ld-scripts/components-mapfile
>>
>>
>> NSUnregisterSelf
>> /export/home/brian/moz-ws/community2/builds/build1101/mozilla/build/unix/gnu-ld-scripts/components-mapfile
>>
>>
>> ld: warning: Symbol referencing errors
>>
>> Those three undefined symbols are provided by the components-mapfile
>> as this:
>> {
>> global:
>> NSGetFactory;
>> NSGetModule;
>> NSRegisterSelf;
>> NSUnregisterSelf;
>> local: *;
>> };
>>
>> I use nm -C libmork.so | grep NSGetFactory, I got following output:
>> [2150] | 0| 0|NOTY |GLOB |0 |UNDEF |NSGetFactory
>>
>> My question is:
>> a. Is there a ld option that I can use to tell ld not to record such
>> global symbols that are not defined in a shared library but exported
>> as public interfaces?
>
> You lost me there. How can a global not be defined in a shared object,
> but yet be exported as part of the shared objects public interface?
>
Sorry for not saying it clearly. In fireofx, each component is expected
but not necessary to define above 4 NS* interfaces.
So that mayfile appears in every command line when building a
component. So if a component doesn't define any of these 4 interfaces,
a warning message like this will be generated.
I can made a specific map file for this component (i.e. libmork.so), but
I think this is not a good idea because we need to remember to modify
the map file if the libmork.so defines those missing NS* someday in future.
If we don't change the map file, will there be any performance penalty
when using dlsym() in fireofx to lookup those missing NS* symbols
compared with
using a specific mapfile (removing those missing symbols)? I use
RTLD_FIRST when dlopen those components.
> Do you mean that these symbols are exported as a public interface from
> a different library than the one you are building? And you wish to
> reference these interfaces? If so, then simply remove them from your
> mapfile. However, do put the interfaces you wish to export from this
> model in the mapfile.
>
> Mapfile definitions, as above, are intended to augment the symbol
> definitions that are found in the relocatable objects that are input to
> the link-edit. In this case, you are asking that only the 4 NS* symbols
> remain global once the output shared library has been created, all other
> symbols within the input relocatable objects will be reduced to locals.
>
> Because ld(1) hasn't found these symbols within the relocatable objects
> used with the link-edit, it assumes your request is erroneous. Usually
> this is caused because of a misspelling.
>
>> b. NSGetModule() will be used as:
>> proc = dlsym(handle,"NSGetModule");
>> proc(...);
>>
>> Is there a better way to define those interfaces to improve
>> performance?
>
> Using a mapfile, you define the interfaces you export, not the interfaces
> you need to import.
Above snippet is used in firefox after dlopen each component like
libmork.so.
>
>> c. What's the purpose of "-M /usr/lib/ld/map.noexstk"?
>
> % cat /usr/lib/ld/map.noexstk
> ....
> # Linker mapfile to create a non-executable stack definition within an
> # executable.
> # The linker does not use this file automatically, so one must use the -M
> # option to cc or ld:
> #
> # cc -M /usr/lib/ld/map.noexstk myprogram.c
> #
> stack = STACK ?RW;
>
> There's really little point in passing this mapfile when building a
> shared
> object. The OSNet applications (dynamic executables) are built with
> this option,
> which exec() uses to ensure a non-executable stack for the process.
> The security folks like this.
>
Will there be any performance losing for dlopen and dlsym after using
the mapfile?
Thanks a lot
Brian
