[fixed in 4.2] C++ visibility attribute

[FredBezies]

In order to test edgy (using vmware server) - before installing it for real - I wanted to build the firefox trunk source, but the build process is killed real soon, too soon :(

I reported the bug on mozilla's bugzilla (https://bugzilla.mozilla.org/show_bug.cgi?id=353150). But Benjamin Smedberg (one of the main coder ?) told me it could be a gcc bug.

So I open a bug here, in order to help.

Here is the error code I get :

c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align
-Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor
-Wno-long-long -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O2 -pipe -w
-fPIC -shared -Wl,-z,defs -Wl,-h,libjar50.so -o libjar50.so nsZipArchive.o
nsWildCard.o nsJARInputStream.o nsJARDirectoryInputStream.o nsJAR.o
nsJARFactory.o nsXPTZipLoader.o nsJARProtocolHandler.o nsJARChannel.o
nsJARURI.o -lpthread -Wl,--version-script
-Wl,../../build/unix/gnu-ld-scripts/components-version-script -Wl,-Bsymbolic
-L../../dist/bin -L../../dist/lib -L../../dist/lib -lmozz -L../../dist/bin
-lxpcom -lxpcom_core -L../../dist/bin -L../../dist/lib -lplds4 -lplc4 -lnspr4
-lpthread -ldl -ldl -lm
nsJAR.o:(.data.rel.ro._ZTV16nsZipReaderCache[vtable for
nsZipReaderCache]+0x54): référence indéfinie vers «
nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
nsJARProtocolHandler.o:(.data.rel.ro._ZTV20nsJARProtocolHandler[vtable for
nsJARProtocolHandler]+0x4c): référence indéfinie vers «
nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
collect2: ld returned 1 exit status

I was using the gcc linked to ubuntu edgy eft knot 3.

It is simple to reproduce : just try to build mozilla trunk code on edgy eft...

[FredBezies (fredbezies-deactivatedaccount)]

I tried again with "gcc version 4.1.2 20060906 (prerelease) (Ubuntu 4.1.1-13ubuntu2)"

Using this .mozconfig, based on optimization flags used by ubuntu version of firefox.

"#
# See http://www.mozilla.org/build/ for build instructions.
#

. $topsrcdir/browser/config/mozconfig

# Options for 'configure' (same as command-line options).
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --disable-freetype2
ac_add_options --enable-pango
ac_add_options --enable-canvas
ac_add_options --enable-svg
ac_add_options --disable-debug
ac_add_options --disable-tests
ac_add_options --enable-optimize="-O2 -pipe -g -fno-strict-aliasing"
ac_add_options --enable-strip
ac_add_options --enable-static
ac_add_options --disable-shared"

And I launch build process, using make -f client.mk build >& buildlog.log in order to log the error.

"rm -f libjar50.so
c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O2 -pipe -g -fno-strict-aliasing -fPIC -shared -Wl,-z,defs -Wl,-h,libjar50.so -o libjar50.so nsZipArchive.o nsWildCard.o nsJARInputStream.o nsJARDirectoryInputStream.o nsJAR.o nsJARFactory.o nsXPTZipLoader.o nsJARProtocolHandler.o nsJARChannel.o nsJARURI.o -lpthread -Wl,--version-script -Wl,../../build/unix/gnu-ld-scripts/components-version-script -Wl,-Bsymbolic -L../../dist/bin -L../../dist/lib -L../../dist/lib -lmozz -L../../dist/bin -lxpcom -lxpcom_core -L../../dist/bin -L../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm
nsJAR.o:(.data.rel.ro._ZTV16nsZipReaderCache[vtable for nsZipReaderCache]+0x54): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
nsJARProtocolHandler.o:(.data.rel.ro._ZTV20nsJARProtocolHandler[vtable for nsJARProtocolHandler]+0x4c): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
collect2: ld returned 1 exit status
make[4]: *** [libjar50.so] Erreur 1
make[4]: quittant le répertoire « /home/fred/log/mozilla/modules/libjar »
make[3]: *** [libs_tier_gecko] Erreur 2
make[3]: quittant le répertoire « /home/fred/log/mozilla »
make[2]: *** [tier_gecko] Erreur 2
make[2]: quittant le répertoire « /home/fred/log/mozilla »
make[1]: *** [default] Erreur 2
make[1]: quittant le répertoire « /home/fred/log/mozilla »
make: *** [build] Erreur 2"

I will attach a bzip2 version of the log in order to help. For me, it will be a blocker and a no-go for switching to edgy eft after its release if I cannot build firefox trunk (which will be firefox 3.0 next year).

[FredBezies (fredbezies-deactivatedaccount)]

Tried again with the newer version of gcc (gcc version 4.1.2 20060920 (prerelease) (Ubuntu 4.1.1-13ubuntu3))

I remove static build options (ie : no more --disable-shared - enable-static options), and it is still crashing, again related to undefined references. Sooner than before.

Here is the end of the build process, before crashing :

rm -f libxpconnect.so
c++ -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O3 -pipe -w -fno-strict-aliasing -fPIC -shared -Wl,-z,defs -Wl,-h,libxpconnect.so -o libxpconnect.so nsScriptError.o nsXPConnect.o xpccallcontext.o xpccomponents.o xpccontext.o xpcconvert.o xpcdebug.o xpcexception.o xpcjsid.o xpcjsruntime.o xpclog.o xpcmaps.o xpcmodule.o xpcruntimesvc.o xpcstack.o xpcstring.o xpcthreadcontext.o xpcthrower.o xpcwrappedjs.o xpcvariant.o xpcwrappedjsclass.o xpcwrappednative.o xpcwrappednativeinfo.o xpcwrappednativejsops.o xpcwrappednativeproto.o xpcwrappednativescope.o XPCNativeWrapper.o -lpthread -Wl,--whole-archive ../loader/libjsloader_s.a -Wl,--no-whole-archive -L../../../../dist/bin -lxpcom -lxpcom_core -L../../../../dist/bin -L../../../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -L../../../../dist/bin -lmozjs -Wl,--version-script -Wl,../../../../build/unix/gnu-ld-scripts/components-version-script -Wl,-Bsymbolic -ldl -lm
nsXPConnect.o:(.data.rel.ro._ZTV11nsXPConnect[vtable for nsXPConnect]+0xc4): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
xpcruntimesvc.o:(.data.rel.ro._ZTV22nsJSRuntimeServiceImpl[vtable for nsJSRuntimeServiceImpl]+0x38): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
xpcthreadcontext.o:(.data.rel.ro._ZTV29nsXPCThreadJSContextStackImpl[vtable for nsXPCThreadJSContextStackImpl]+0x48): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
xpcwrappedjs.o: In function `nsXPCWrappedJS::GetWeakReference(nsIWeakReference**)':
xpcwrappedjs.cpp:(.text+0x22a): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
collect2: ld returned 1 exit status
make[5]: *** [libxpconnect.so] Erreur 1
make[5]: quittant le répertoire « /home/fred/logs/mozilla/js/src/xpconnect/src »
make[4]: *** [libs] Erreur 2
make[4]: quittant le répertoire « /home/fred/logs/mozilla/js/src/xpconnect »
make[3]: *** [libs_tier_gecko] Erreur 2
make[3]: quittant le répertoire « /home/fred/logs/mozilla »
make[2]: *** [tier_gecko] Erreur 2
make[2]: quittant le répertoire « /home/fred/logs/mozilla »
make[1]: *** [default] Erreur 2

I think that the important part is :

"xpcthreadcontext.o:(.data.rel.ro._ZTV29nsXPCThreadJSContextStackImpl[vtable for nsXPCThreadJSContextStackImpl]+0x48): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
xpcwrappedjs.o: In function `nsXPCWrappedJS::GetWeakReference(nsIWeakReference**)':
xpcwrappedjs.cpp:(.text+0x22a): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(n...

[FredBezies (fredbezies-deactivatedaccount)]

I looked at the very first warning, and saw :

"checking For gcc visibility bug with class-level attributes (GCC bug 26905)... c++: -z: linker input file unused because linking not done
c++: defs: linker input file unused because linking not done
test: 1: ==: unexpected operator
no"

Is this bug related to gcc bug 26905, which was marked as closed for more than a month ?

[FredBezies (fredbezies-deactivatedaccount)]

I tried to use gcc 4.0 instead of gcc 4.1, and it is worse. So, is there any hope to see this bug confirmed ? Or should I have to let it die ?

/me thinks to move to Fedora 6 when it will be released... And it will be a great disappointment :(

[Matthias Klose (doko)]

please have a look at the firefox source package as distributed by Ubuntu to see which patches are applied and which build options are used. You may want to ask on irc in #ubuntu-users for help.

[FredBezies (fredbezies-deactivatedaccount)]

So, I think you can close this bug because :

- I don't care about fx source package, this bug is about the trunk source which I grab for mozilla.org CVS.
- I don't think any patches applied on the 2.0 branch will help at all on the trunk source (development version which are building OK with gcc 4.0 and Dapper)
- Build options are displayed in about:buildconfig, so, I don't need to look at it in package description.

You can close this bug, because I think I will never install Edgy with such a buggy version of gcc.

Now, do what you want !

[FredBezies (fredbezies-deactivatedaccount)]

Just a last comment to tell you that :

- using gcc 4.0 / g++ 4.0 and related packages (libc++ or something like that development package) doesn't help at all.
- I still have this :

"g++-4.0 -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -fshort-wchar -pthread -pipe -DNDEBUG -DTRIMMED -O3 -pipe -w -march=pentium4 -fPIC -shared -Wl,-z,defs -Wl,-h,libjar50.so -o libjar50.so nsZipArchive.o nsWildCard.o nsJARInputStream.o nsJARDirectoryInputStream.o nsJAR.o nsJARFactory.o nsXPTZipLoader.o nsJARProtocolHandler.o nsJARChannel.o nsJARURI.o -lpthread -Wl,--version-script -Wl,../../build/unix/gnu-ld-scripts/components-version-script -Wl,-Bsymbolic -L../../dist/bin -L../../dist/lib -L../../dist/lib -lmozz -L../../dist/bin -lxpcom -lxpcom_core -L../../dist/bin -L../../dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl -ldl -lm
nsJAR.o:(.gnu.linkonce.d._ZTV16nsZipReaderCache[vtable for nsZipReaderCache]+0x54): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
nsJARProtocolHandler.o:(.gnu.linkonce.d._ZTV20nsJARProtocolHandler[vtable for nsJARProtocolHandler]+0x4c): référence indéfinie vers « nsSupportsWeakReference::GetWeakReference(nsIWeakReference**) »
collect2: ld a retourné 1 code d'état d'exécution
make[4]: *** [libjar50.so] Erreur 1
make[4]: quittant le répertoire « /home/fred/logs/fox/mozilla/modules/libjar »
make[3]: *** [libs_tier_gecko] Erreur 2
make[3]: quittant le répertoire « /home/fred/logs/fox/mozilla »
make[2]: *** [tier_gecko] Erreur 2
make[2]: quittant le répertoire « /home/fred/logs/fox/mozilla »
make[1]: *** [default] Erreur 2
make[1]: quittant le répertoire « /home/fred/logs/fox/mozilla »
make: *** [build] Erreur 2"

So, I think there is a bug in edgy for gcc 4.1.1 but also 4.0... Strange thing is that the same code - not patched at all - is built flawlessly under dapper.

I just can tell you I am fed up with that now. I am sorry you cannot find why I could not go past this part of build process.

Now do what you want with that bug.

Have a good day.

[Matthias Klose (doko)]

I didn't have a chance to look at this. you may want to check the gcc-snapshot package, which contains a version of the gcc trunk, if it suits your needs. please let us know, if you need a more recent version of this package.

[FredBezies (fredbezies-deactivatedaccount)]

I am using gcc versions from ubuntu repositories.

But I noticed something strange. On both case, we have : "collect2: ld returned 1 exit status" / "collect2: ld a retourné 1 code d'état d'exécution".

So this could be related to ld, and to binutils package ?!

It could be a possible answer, because seeing this bug on both version of gcc, knowing that I am using successfully gcc 4 on dapper makes me curious.

[FredBezies (fredbezies-deactivatedaccount)]

Somebody told me there is another bug which has the "same" error listing before build process crash. It touched synaptic building process (bug 62461).

Could there be any relationship between both ?

[Matthias Klose (doko)]

> Could there be any relationship between both ?

I'm not aware that mozilla uses the #pragma interface stuff.

[FredBezies (fredbezies-deactivatedaccount)]

I don't say that, I just noticed error logs were similar on some points.

Just trying to understand why building process crash. Till it crash, for me, edgy won't be installed on my hard drive :(

[Matthias Klose (doko)]

FredBezies schrieb:
> I don't say that, I just noticed error logs were similar on some points.

please recheck with the gcc-snapshot package.

[FredBezies (fredbezies-deactivatedaccount)]

I will try today, or as soon as I can.

[FredBezies (fredbezies-deactivatedaccount)]

Completely unuseful. Or at least, half unuseful.

Build process is ok, but firefox crashes on start, core dumping :(

fred@ubuntu:~/logs/firefox$ Segmentation fault (core dumped)

[1]+ Exit 139 ./firefox

Another idea ?

[FredBezies (fredbezies-deactivatedaccount)]

Don't worry anymore. I decided to upgrade to edgy and to trash firefox pre-3.0 alpha1 build process. I will use official nightlies instead of homemade ones.

Thanks anyway for having tried to find what was bugging.

[Matt Zimmerman (mdz)]

I'm confirming this under the assumption that it's the same bug which Martin observed in a firefox build, i.e. gcc bug 20297 or 26905. We have a workaround in place for edgy, but this should be fixed for feisty.

[FredBezies (fredbezies-deactivatedaccount)]

Which workaround ?

I am getting interested in this. Too bad the fix could not be inserted before feisty (7.04 ?)

[Matthias Klose (doko)]

see the firefox changelog, its in edgy.

  * configure: Fix bashism to let the gcc visibility=hidden bug detection
    work.

[c7d2f5c8667d26fffd5e7772d632c76d (c7d2f5c8667d26fffd5e7772d632c76d-deactivatedaccount)]

Actually the latest firefox source in edgy (firefox_2.0+0dfsg-0ubuntu3.diff.gz) still has the bug, since the configure test (which is taken from gecko trunk) still contains this bashism:

+ if test `grep -c "@PLT" conftest.S` == 0; then

This causes the gcc bug to go undetected.

[Matt Zimmerman (mdz)]

On Thu, Oct 26, 2006 at 10:24:28AM -0000, chpe wrote:
> Actually the latest firefox source in edgy (firefox_2.0+0dfsg-
> 0ubuntu3.diff.gz) still has the bug, since the configure test (which is
> taken from gecko trunk) still contains this bashism:
>
> + if test `grep -c "@PLT" conftest.S` == 0; then
>
> This causes the gcc bug to go undetected.

It looks to be patched in configure, but not configure.in, so it will work
as-is, but resurface if configure is regenerated.

mdz@drescher:~/firefox-2.0+0dfsg$ grep @PLT configure configure.in
configure: if test `grep -c "@PLT" conftest.S` = 0; then
configure: if test `grep -c "@PLT" conftest.S` = 0; then
configure.in: if test `grep -c "@PLT" conftest.S` == 0; then
configure.in: if test `grep -c "@PLT" conftest.S` == 0; then

--
 - mdz

[Matthias Klose (doko)]

needs the configure.in fix in edgy

[Matthias Klose (doko)]

the visibility patches were backported from 4.2 to 4.1.1-18ubuntu2.

[Matthias Klose (doko)]

reverted the patch, showing regressions for kdelibs4 on amd64; unlikely to be fixed for 4.1, fixed in 4.2

[Alexander Sack (asac)]

Our packages for Firefox et al ship a patch for this. So closing the firefox track for this issue. If I missed something reopen...

[Nanley Chery (nanoman)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. However, I am closing it because the bug has been fixed in the latest development version of Ubuntu - the Gutsy Gibbon. It won't be fixed in previous versions of Ubuntu because the bug doesn't fit requirements for backporting. See [WWW] https://help.ubuntu.com/community/UbuntuBackports for more information

[Matthias Klose (doko)]

Nanley, please don't close bug reports which are NOT fixed. It's an old report, it's still not fixed in the 4.1, so both the reassignment and the status change are completely wrong. reverted the change.

[Nanley Chery (nanoman)]

I am sorry for changing the status, but I do want to mention that I did not reassign this bug to another developer. I am sorry for any problem I have caused.

[Matthias Klose (doko)]

gcc-4.2 is now the default compiler for hardy