340446 - invisible string symbols problem

Status: NEW

(Core :: XPCOM, defect)

Description

[Christian Persch (GNOME) (away; not receiving bug mail)]

Since the checkin from bug 337730, it's impossible to build Epiphany or Yelp [http://bugzilla.gnome.org/show_bug.cgi?id=343044] against xulrunner trunk since it fails to link due to unresolved symbols nsA[C]String::BeginReading and other string symbols:
yelp-Yelper.o: In function `nsCString_external::get() const':/opt/xulrunner-trunk-debug/include/xulrunner-1.9a1/xpcom/nsStringAPI.h:519: undefined reference to `nsACString::BeginReading() const'

Comment 1

[Christian Persch (GNOME) (away; not receiving bug mail)]

Attachment: testcase

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

Comment 2

[Darin Fisher]

What is your link line?

Comment 3

[Darin Fisher]

perhaps you are not linking to libxpcomglue_s.a ?

Comment 4

[Christian Persch (GNOME) (away; not receiving bug mail)]

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.

Comment 5

[Darin Fisher]

(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.

Comment 6

[Christian Persch (GNOME) (away; not receiving bug mail)]

(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?

Comment 7

[Benjamin Smedberg]

> 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.

Comment 8

[Christian Persch (GNOME) (away; not receiving bug mail)]

(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.

Comment 9

[Benjamin Smedberg]

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.

Comment 10

[Christian Persch (GNOME) (away; not receiving bug mail)]

(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.

Comment 11

[Benjamin Smedberg]

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

Comment 12

[Philip Langdale]

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.

Comment 13

[Marco Pesenti Gritti]

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?