Closed
Bug 87258
Opened 23 years ago
Closed 23 years ago
symbols erroneously exported in nsIGenericFactory.h
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: sam, Assigned: kandrot)
Details
Attachments
(2 files)
1.06 KB,
patch
|
Details | Diff | Splinter Review | |
1.21 KB,
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-ac13 i586; en-US; rv:0.9.1) Gecko/20010620 BuildID: The NS_IMPL_NSGETMODULE_WITH_DTOR macro in nsIGenericFactory.h declares several symbols (NSGetModule_components_count and NSGetModule_components). These symbols are used nowhere else, and can cause problems if they are used to resolve symbols from other libraries by the run-time linker. This bug is probably not Linux-specific. Reproducible: Always Steps to Reproduce: 1. Build an XPCOM component library. 2. Build a program that uses XPCOM components, and is also linked against the component library (-lcomponent on compiler command line). 3. Run the program, watch it not find some factories. Using a debugger, trace the code into nsNativeComponentLoader::GetFactoryFromModule and wonder why it doesn't work. Then realise it's looking at the wrong component list. Actual Results: 1024[80516d0]: nsNativeComponentLoader: loading "/sothis/projects1/mozilla/mozilla-0.8.1-debug-enabled/dist/lib/components/libnecko.so" 1024[80516d0]: nsNativeComponentLoader: Factory creation FAILED for abs:/sothis/projects1/mozilla/mozilla-0.8.1-debug-enabled/dist/lib/components/libnecko.so 1024[80516d0]: ###!!! ASSERTION: Factory creation failed: 'NS_SUCCEEDED(rv)', file nsNativeComponentLoader.cpp, line 157 1024[80516d0]: ###!!! Break: at file nsNativeComponentLoader.cpp, line 157 1024[80516d0]: nsComponentManager: CreateInstance({be9a53ae-c7e9-11d3-8cda-0060b0fc14a3}) FAILED Expected Results: It should have found the correct modules and created the correct factory.
Reporter | ||
Comment 1•23 years ago
|
||
Updated•23 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 2•23 years ago
|
||
All of this code has changed for the making of the static-link build. Does this still happen with the latest code? If so, and you can supply another patch, I will r=, and get the other needed approves, then check it in. Thanks.
Status: NEW → ASSIGNED
Reporter | ||
Comment 3•23 years ago
|
||
This still occurs with 0.9.2, as the symbols are still exported with the same names. The static link build names them so they don't collide, but they still collide when built into dynamic objects.
Reporter | ||
Comment 4•23 years ago
|
||
Comment 5•23 years ago
|
||
looks like this has been fixed with the new static build system.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•