bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

symbols erroneously exported in nsIGenericFactory.h

RESOLVED INVALID

Status

()

Core
XPCOM
RESOLVED INVALID
17 years ago
17 years ago

People

(Reporter: Sam Couter, Assigned: Edward Kandrot)

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

17 years ago
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

17 years ago
Created attachment 39652 [details] [diff] [review]
Trivial patch; declare symbols as 'static'
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

17 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

17 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

17 years ago
Created attachment 44199 [details] [diff] [review]
Patch updated for 0.9.2

Comment 5

17 years ago
looks like this has been fixed with the new static build system.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.