libxul step 2 - everything up through widget (except

RESOLVED FIXED in mozilla1.8beta2


Core Graveyard
Embedding: GRE Core
14 years ago
2 years ago


(Reporter: Benjamin Smedberg, Assigned: Benjamin Smedberg)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(2 attachments)



14 years ago
I'm not going to touch right now, I haven't thought through the
issues with frozen symbols there yet. But it doesn't matter, because it doesn't
link against xpcom/xpcom_core anyway. This patch combines everything up through

Comment 1

14 years ago
Created attachment 168299 [details] [diff] [review]
libxul tier 2, rev 1


14 years ago
Attachment #168299 - Flags: review?(darin)

Comment 2

14 years ago
Comment on attachment 168299 [details] [diff] [review]
libxul tier 2, rev 1

>Index: config/

>+# Force XPCOM/widget/gfx methods to be _declspec(dllexport) when we're
>+# building libxul libraries
>+ifeq ($(OS_ARCH),WINNT)

I wouldn't make this specific to WINNT.  Eventually, hidden visibility
stuff will be tied into these macros as well (See brian's patch).  And,
anyways, what about OS/2? ;-)

>Index: ipc/ipcd/extensions/transmngr/build/

what about the other IPC extension libs?  not that it really

>Index: toolkit/library/nsDllMain.cpp

>+ #include <windows.h>
>+ #include "nsToolkit.h"
>+ extern "C" {
>+ extern HINSTANCE _pr_hInstance;
>+ }
>+ #if defined(__GNUC__)
>+// If DllMain gets name mangled, it won't be seen.
>+extern "C" {

off-by-one indenting?

>\ No newline at end of file


>+    nsRegionRectIterator i(a);
>+    i.Next();
>+    i.Prev();
>+    i.Reset();

Are you sure it is necessary to call each method?  Once you 
instantiate a class that's usually enough to make sure that
all of its methods are included.

>\ No newline at end of file


Attachment #168299 - Flags: review?(darin) → review+

Comment 3

14 years ago
For some reason, it appears necessary to call at least more than one method.
This may have something to do with the fact that this class does not have a
vtable, or apparently any internal callers. Once I incoporate the rest of tier_9
in libxul part 3 we don't have to dllexport the GFX stuff at all, and we can get
rid of that dlldeps file.

Fixed on trunk with other nits picked.
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 4

14 years ago
This seems to have busted the linux xulrunner build in a couple ways:

 gfx/src/psshared           <- needed LIBXUL_LIBRARY=1 (already fixed)
 libpr0n/decoders/icon/gtk  <- needs to be a standalone DSO for gnome integration
 modules/plugin/samples/... <- need to link against libxul (or not??)

I didn't get any further with my trunk build because I ran out of time.

Comment 5

14 years ago
Fun stuff here ;) I fixed up psshared so that it was in the toolkit/library link
list, and a couple of other linker errors. libxul should now build on linux, but
only if you set LD_LIBRARY_PATH=/path/to/dist/bin.  This is because
depends on, but is not specified explicitly on the link
line for all the tier 50/99 components and test apps. This can be fixed by bug
Blocks: 274089

Comment 6

14 years ago
I'm going to reopen this to get the -rpath-link magic.
Resolution: FIXED → ---

Comment 7

14 years ago
Created attachment 168508 [details] [diff] [review]
Use -rpath-link to pull needed by


14 years ago
Attachment #168508 - Flags: review?(cls)

Comment 8

14 years ago
Comment on attachment 168508 [details] [diff] [review]
Use -rpath-link to pull needed by

so, if this is needed, then why is the xulrunner tinderbox green?

Comment 9

14 years ago
> so, if this is needed, then why is the xulrunner tinderbox green?

nevermind, i should have looked at the tinderbox log files first... i see that
the tinderbox script sets LD_LIBRARY_PATH.

Comment 10

14 years ago
Comment on attachment 168508 [details] [diff] [review]
Use -rpath-link to pull needed by

I don't think all linkers support -rpath-link.	Also, we've purposefully
avoided using anything rpath related up to this point.	It is possible (in an
admittedly contrived situation) that using -rpath-link could wind up linking
against the wrong version of mozjs...say libxul & mozjs were installed on the
system but there happens to be mozjs in $(DIST)/bin.  I think you'd be better
off just adding $(MOZ_JS_LIBS) to LIBXUL_LIBS until libmozjs gets incorporated
into libxul.
Attachment #168508 - Flags: review?(cls) → review-

Comment 11

13 years ago
Chris, we decided to keep as a separate sharedlib permanently. I'm
going to need some sort of solution like this soon, for code which links only
against the frozen symbols in and should not link against

Comment 12

13 years ago
The problem mentioned in comment #5 can be solved by adding MOZ_JS_LIBS to
LIBXUL_LIBS.  I think that's going to be required anyway for linkers which
require all symbols to be resolved at link time, like the AIX & HP-UX linkers. 
Comment #11 sounds like it's addressing a different problem.  I feel like I'm
missing some context here.

Comment 13

13 years ago
I've got two related problems.

1) Gecko code which links against non-frozen symbols in libxul. Adding
MOZ_JS_LIBS to the link line will fix this problem, though I don't like it.

2) Application code which only links against the frozen symbols in
This will be the toolkit apps as I can wean them off non-frozen symbols. This
code explicitly must not link against or, even though has an ELF dependency on these libs. In this case (AFAICT) either
the -rpath-link flag or munging the environment is necessary to achieve the
desired result.

Comment 14

13 years ago
Comment on attachment 168508 [details] [diff] [review]
Use -rpath-link to pull needed by

OK, we've decided to do this anyway, and deal with the ports that fail as
necessary. Got r=darin over IRC
Attachment #168508 - Flags: review- → review+

Comment 15

13 years ago
All fixed on trunk, finally!
Last Resolved: 14 years ago13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8beta2
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.