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

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.

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?