Closed Bug 87258 Opened 23 years ago Closed 23 years ago

symbols erroneously exported in nsIGenericFactory.h

Categories

(Core :: XPCOM, defect)

x86
Linux
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: sam, Assigned: kandrot)

Details

Attachments

(2 files)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: