[-dev] include static libraries: libxpcomglue.a, libxpcomglue_s.a

Bug #62802 reported by c7d2f5c8667d26fffd5e7772d632c76d on 2006-09-28
4
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Confirmed
Medium
firefox (Ubuntu)
Wishlist
Mozilla Bugs
firefox-3.0 (Ubuntu)
Undecided
Unassigned
xulrunner-1.9 (Ubuntu)
Undecided
Unassigned

Bug Description

Binary package hint: firefox

The firefox (or -dev) package should contain the static libraries libxpcomglue.a and libxpcomglue_s.a. Those are necessary when you want to build a standalone component without depending on libxpcom / depending on nonfrozen API from xpcom.

Created attachment 224476
testcase

This compiles and links with 1.8 but fails with xulrunner trunk.

What is your link line?

perhaps you are not linking to libxpcomglue_s.a ?

Yes, I'm not linking static libs; Epiphany (and Yelp) don't use the glue but link dynamically with libxpcom. (I couldn't use the glue in Epiphany even if I wanted to, because I need to use the threadsafe isupports macros in some places).

The actual link line is rather long:
g++ -fno-rtti -fshort-wchar [some -Wsome-warning flags] -o yelp [object file list] [gnome libraries] -L/opt/xulrunner-trunk-debug/lib/xulrunner-1.9a1 -lxpcom -lplds4 -lplc4 -lnspr4 -lpthread -ldl -Wl,--rpath -Wl,/opt/xulrunner-trunk-debug/lib/xulrunner-1.9a1

For the testcase I used:
g++ -fno-rtti -fshort-wchar `pkg-config --libs --cflags xulrunner-xpcom` -o test test.cpp -Wl,--rpath -Wl,/opt/xulrunner-trunk-debug/lib/xulrunner-1.9a1

Using -fvisibility-inlines-hidden or -fvisibility=hidden makes no difference.

(In reply to comment #4)
> Yes, I'm not linking static libs; Epiphany (and Yelp) don't use the glue but
> link dynamically with libxpcom. (I couldn't use the glue in Epiphany even if I
> wanted to, because I need to use the threadsafe isupports macros in some
> places).

libxpcomglue_s.a can be used with the threadsafe isupports macros. It is only libxpcomglue.a (confusingly named) that does not define those macros.

> The actual link line is rather long:
> g++ -fno-rtti -fshort-wchar [some -Wsome-warning flags] -o yelp [object file
> list] [gnome libraries] -L/opt/xulrunner-trunk-debug/lib/xulrunner-1.9a1
> -lxpcom -lplds4 -lplc4 -lnspr4 -lpthread -ldl -Wl,--rpath
> -Wl,/opt/xulrunner-trunk-debug/lib/xulrunner-1.9a1

For the mozilla parts, change this to be:

-lxpcomglue_s -lxpcom -lplds4 -lplc4 -lnspr4

That should work.

(In reply to comment #5)
> (In reply to comment #4)
> > Yes, I'm not linking static libs; Epiphany (and Yelp) don't use the glue but
> > link dynamically with libxpcom. (I couldn't use the glue in Epiphany even if I
> > wanted to, because I need to use the threadsafe isupports macros in some
> > places).
>
> libxpcomglue_s.a can be used with the threadsafe isupports macros. It is only
> libxpcomglue.a (confusingly named) that does not define those macros.
Thanks, I didn't know that :)

> For the mozilla parts, change this to be:
>
> -lxpcomglue_s -lxpcom -lplds4 -lplc4 -lnspr4
>
> That should work.

Ok, this does work, thanks!

So I see 3 bugs here:
0) If linking with -lxpcomglue_s is required, firefox-xpcom.pc file should include that in the Libs: line.
1) libxpcomglue_s.a isn't installed by "make -f client.mk install", it's only available in the dist/ tree.
2) I don't want to link to static libraries at all; can this be provided as a dynamic library?

> 2) I don't want to link to static libraries at all; can this be provided as a
> dynamic library?

No. The whole point of the glue is to be a static library which insulates client code and ensures that it only uses frozen exports from libxpcom.

(In reply to comment #7)
> > 2) I don't want to link to static libraries at all; can this be provided as a
> > dynamic library?
>
> No. The whole point of the glue is to be a static library which insulates
> client code and ensures that it only uses frozen exports from libxpcom.

Maybe you misunderstood me. I don't insist on a dynamic version of the 'glue' but I do insist on a dynamic lib providing the string symbols. I can dynamically link xpcom and libxul, and many XPCOM interfaces that libxul provides use A[C]String. To use them I absolutely need those symbols.

The internal-linkage string symbols are not frozen and will become hidden-visibility (not exported) in the 1.9 cycle. "internal linkage" client code will not be possible.

(In reply to comment #9)
> The internal-linkage string symbols are not frozen and will become
> hidden-visibility (not exported) in the 1.9 cycle. "internal linkage" client
> code will not be possible.

I don't understand... this is not about internal strings (#include <nsString.h>) but about external, frozen strings (#include <nsStringAPI.h>) as the testcase shows.

We have separated out the frozen string symbols (C exports from libxpcom.so) into nsXPCOMStrings.h. The glued C++ string helper symbols in nsStringAPI.h are hidden-visibility provided by libxpcomglue_s.a

If xpcomglue_s.a is required to use strings, then it should be available for linking in the distributed builds. Right now things are completely broken - no one can use it unless they built xulrunner/firefox/whatever themselves.

Binary package hint: firefox

The firefox (or -dev) package should contain the static libraries libxpcomglue.a and libxpcomglue_s.a. Those are necessary when you want to build a standalone component without depending on libxpcom / depending on nonfrozen API from xpcom.

Same problem happens with the JSAPI libraries and makes it impossible to compile packages like avidemux

Changed in firefox:
assignee: nobody → mozillateam
John Vivirito (gnomefreak) wrote :

Can you please file this at: https://bugzilla.mozilla.org/ and give us the link.

Changed in firefox:
status: Unconfirmed → Needs Info

This is NOT an upstream bug. Those libraries are built; the bug is that ubuntu's firefox[-dev] package doesn't contain them.

Changed in firefox:
importance: Undecided → Medium
Alexander Sack (asac) wrote :

do those static libs get installed by make install? Otherwise, its somehow an upstream bug. Though this does not mean that we can't fix it without help of upstream.

Changed in firefox:
importance: Medium → Wishlist

https://bugzilla.mozilla.org/show_bug.cgi?id=340446 is about installing these static libs. But upstream doesn't seem to care about make install; and it surely can be fixed without upstream.

Alexander Sack (asac) wrote :

Moving on to state confirmed and adapt tags appropriately

Changed in firefox:
status: Needs Info → Confirmed
Alexander Sack (asac) wrote :

patch needs to be developed/contributed.

Further it needs to be clarified what are exported (frozen) api parts and which ones are hidden. Work with upstream to figure this out in https://bugzilla.mozilla.org/show_bug.cgi?id=340446

There is absolutely NO frozen API in those libraries. Their whole point is that they contain unfrozen APIs and therefore you should link them statically into your programme.

Changed in firefox:
status: Unknown → Unconfirmed
David Farning (dfarning) on 2007-02-24
Changed in firefox:
assignee: mozillateam → mozilla-bugs

http://benjamin.smedbergs.us/blog/2007-05-15/xulrunner-what-we-are-doing/

If I understand the post correctly, shared runtime support has been dropped from the 1.9 roadmap. Is the separate static library still useful in any way or can we go back to 1.8 linking?

Changed in firefox:
status: Unconfirmed → Confirmed

Is there any progress on this? It really makes it impossible to develop native firefox extensions which will be portable between static or dynamic built installations of ff, let alone support ff2 and ff3 in the same binary. You basically have to build from moz source, OR support only ubuntu ff and break on the static binaries downloaded from e.g. getfirefox.com.

Martin Kalén (martin-kalen) wrote :

Those libs are now in the xulrunner-1.9-dev package in Ubuntu. See http://benjamin.smedbergs.us/blog/2007-05-15/xulrunner-what-we-are-doing/ for some background information.

On Fri, May 23, 2008 at 09:37:44PM -0000, Martin Kalén wrote:
> Those libs are now in the xulrunner-1.9-dev package in Ubuntu. See
> http://benjamin.smedbergs.us/blog/2007-05-15/xulrunner-what-we-are-
> doing/ for some background information.
>

right, adjusting status accordingly ...

 affects ubuntu/firefox
 status wontfix

 affects ubuntu/xulrunner-1.9
 status fixreleased

 affects ubuntu/firefox-3.0
 status invalid

 - Alexander

Changed in firefox:
status: Confirmed → Won't Fix
Changed in firefox:
importance: Unknown → Medium
Changed in firefox:
status: Confirmed → Unknown
Changed in firefox:
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.