557125 - [Linux64 SeaMonkey 2.1] comm-central-trunk build on tinderbox fails to compile after bug 551254 (testplugin / moz_xmalloc)

Status: VERIFIED FIXED

(Core :: XPCOM, defect)

Description

[Serge Gautherie (:sgautherie)]

{
http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1270405112.1270405535.20653.gz
Linux x86-64 comm-central-trunk build on 2010/04/04 11:18:32

/tools/gcc/bin/g++  -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -pedantic -gstabs+ -fno-strict-aliasing -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -gstabs+ -Os -freorder-blocks -fno-reorder-functions -fomit-frame-pointer -finline-limit=50 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12 -I/usr/include/gtk-unix-print-2.0   -fPIC -shared -Wl,-z,defs -Wl,-h,libnptest.so -o libnptest.so  nptest.o nptest_utils.o nptest_gtk2.o     -lpthread    -Wl,-rpath-link,/builds/slave/comm-central-trunk-linux64/build/objdir/mozilla/dist/bin -Wl,-rpath-link,/usr/local/lib  -L/lib64 -lgtk-x11-2.0 -latk-1.0 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   -L/usr/lib64 -lX11  -lXext -ldl -lm    
nptest.o: In function `addRange(InstanceData*, char const*)':
/builds/slave/comm-central-trunk-linux64/build/objdir/mozilla/modules/plugin/test/testplugin/../../../../dist/include/mozilla/mozalloc.h:222: undefined reference to `moz_xmalloc'
nptest.o: In function `checkGCRace(NPObject*, _NPVariant const*, unsigned int, _NPVariant*)':
/builds/slave/comm-central-trunk-linux64/build/objdir/mozilla/modules/plugin/test/testplugin/../../../../dist/include/mozilla/mozalloc.h:222: undefined reference to `moz_xmalloc'
nptest.o: In function `streamTest(NPObject*, _NPVariant const*, unsigned int, _NPVariant*)':
/builds/slave/comm-central-trunk-linux64/build/objdir/mozilla/modules/plugin/test/testplugin/../../../../dist/include/mozilla/mozalloc.h:222: undefined reference to `moz_xmalloc'
/builds/slave/comm-central-trunk-linux64/build/objdir/mozilla/modules/plugin/test/testplugin/../../../../dist/include/mozilla/mozalloc.h:246: undefined reference to `moz_free'
nptest.o: In function `FinishGCRace(void*)':
/builds/slave/comm-central-trunk-linux64/build/objdir/mozilla/modules/plugin/test/testplugin/../../../../dist/include/mozilla/mozalloc.h:246: undefined reference to `moz_free'
nptest.o: In function `NPP_Destroy':
/builds/slave/comm-central-trunk-linux64/build/objdir/mozilla/modules/plugin/test/testplugin/../../../../dist/include/mozilla/mozalloc.h:246: undefined reference to `moz_free'
/builds/slave/comm-central-trunk-linux64/build/objdir/mozilla/modules/plugin/test/testplugin/../../../../dist/include/mozilla/mozalloc.h:246: undefined reference to `moz_free'
nptest.o: In function `NPP_New':
/builds/slave/comm-central-trunk-linux64/build/objdir/mozilla/modules/plugin/test/testplugin/../../../../dist/include/mozilla/mozalloc.h:222: undefined reference to `moz_xmalloc'
nptest.o: In function `testplugin_URLNotify(_NPP*, char const*, short, void*)':
/builds/slave/comm-central-trunk-linux64/build/objdir/mozilla/modules/plugin/test/testplugin/../../../../dist/include/mozilla/mozalloc.h:246: undefined reference to `moz_free'
collect2: ld returned 1 exit status
make[7]: *** [libnptest.so] Error 1
}

Comment 1

[Serge Gautherie (:sgautherie)]

CC'ed Benjamin to get help, per
https://developer.mozilla.org/en/Supported_build_configurations
"Tier-2 platforms
Linux/x86-64 — maintained by Benjamin Smedberg"

Comment 2

[Benjamin Smedberg]

It seems pretty clear that the testplugin should not be using the infallible allocator libraries. cjones, how do we make that happen, and it should probably be documented at https://developer.mozilla.org/Special:Tags?tag=Build+Glossary

Comment 3

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

(In reply to comment #2)
> It seems pretty clear that the testplugin should not be using the infallible
> allocator libraries. cjones, how do we make that happen, and it should probably
> be documented at https://developer.mozilla.org/Special:Tags?tag=Build+Glossary

That testplugin links on m-c suggests to me it's building/linking with the wrong flags, it should be non-XPCOM.  That's problem 1.  If that's indeed the case and we fix it, we'd get a compiler #error about trying to use the STL wrappers from code we're not supposed to, problem 2.  Bug 551254 comment 47 patches the second part.  Looking into this later today.

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

My guess was wrong; nm says that m-c nptest.o and libnptest.so are free of libxul dependencies.  This means either the code is different or compiler flags are introducing the dependency.  Checking.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Wfm on a local seamonkey build with a slightly modified .mozconfig taken from 

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1270585778.1270585811.29912.gz
--------------
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/../sm-opt
mk_add_options MOZ_MAKE_FLAGS="-s -j16"

# [tinderbox mozconfig below]
ac_add_options --enable-application=suite
ac_add_options --enable-optimize
ac_add_options --enable-update-channel=nightly
ac_add_options --enable-update-packaging
ac_add_options --disable-debug
ac_add_options --enable-tests
ac_add_options --enable-codesighs

#CC=/tools/gcc/bin/gcc
#CXX=/tools/gcc/bin/g++

export CFLAGS="-gstabs+"
export CXXFLAGS="-gstabs+"

# For NSS symbols
export MOZ_DEBUG_SYMBOLS=1
ac_add_options --enable-debug-symbols="-gstabs+"

# Needed to enable breakpad in application.ini
export MOZILLA_OFFICIAL=1
--------------

Really don't know what to say, especially since the seamonkey linux/x86-64 nightly is green.

Comment 6

[Serge Gautherie (:sgautherie)]

Good point!

Fwiw, the nightly seems to have more steps, like
{
'rm -rf ...'
rm -rf build

cleanup old symbols failed
find 20* -maxdepth 2 -mtime +7 -exec rm -rf {} \;
}
I didn't check them all though.

Ftr, the mozconfig diff between build and nightly is:
{
# static build with tests is not supported (e.g. in crashreporter)
ac_add_options --disable-tests

ac_add_options --enable-static
ac_add_options --disable-shared
}
But your local build passed so this diff is probably inconclusive.

Comment 7

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)

Yet, to be explicit:
*Nightly couldn't fail on a test it doesn't compile!
*Maybe there is a build environment difference between the VM and your local env that would explain the different outcome?

Comment 8

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Ah yes, --disable-tests! :(

Let me see if I can dig up anything else.

Comment 9

[Robert Kaiser]

BTW, Mnyromyr has said he runs into the same problem with linux64 builds on his machine.

Comment 10

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Happen to know which gcc version?

Comment 11

[Robert Kaiser]

The SeaMonkey linux64 box uses gcc-4.2.3 currently - that might very well be a difference to the current setup used by the Firefox boxes, as the setup used there now is quite hard for me to duplicate since they switched to driving everything with puppet.

No idea what Mnyromyr is using, he'll have to answer that himself.

Comment 12

[Serge Gautherie (:sgautherie)]

(In reply to comment #11)

Ftr,
https://wiki.mozilla.org/ReferencePlatforms/Linux-CentOS-5.0_64-bit
{
Make GCC 4.2.3
...
Puppet Installation
*GCC 4.3.3
}
Then which version to use to build is not as explicit as it could be :-|

Comment 13

[Serge Gautherie (:sgautherie)]

(In reply to comment #12)

And, fwiw,
https://developer.mozilla.org/En/Developer_Guide/Build_Instructions/Linux_Prerequisites
{
RedHat Enterprise Linux (RHEL)/CentOS/Fedora

yum install ... gcc-c++ ...
}

Comment 14

[Serge Gautherie (:sgautherie)]

And fwiw,
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1270594676.1270596776.5220.gz&fulltext=1
uses dwarf-2 instead of stabs+
and has
{
# We're using GCC 4.2 which has a bug we can work around.
export ac_cv_have_visibility_class_bug=yes
}
and moreover seems to be building with "gcc version 4.3.3 (GCC) ".

Comment 15

[Robert Kaiser]

Please don't overload cjones with information that might be unrelated to the actual problem, like the linux prerequisites from MDC which anyone needs to follow to get any build going. Also dwarf-2 vs. gstabs+ is just symbols for debugger and crash reporter, which have nothing to do with this bug.

Comment #5 makes it clear that this all makes no difference. The compiler version might, though, as Firefox probably uses 4.3.3 while SeaMonkey uses 4.2.3 right now on the linux64 box.

And, as a sidenote, my somewhat-rant about being hard to follow thing since puppet happened is now bug 557704 and also not directly related with the problem this bug is describing (though it's possible that updating the SeaMonkey machine to what Firefox has could fix this bug at least for our buildslave if I would know what to do, but it still would not fix it for people like Mnyromyr who can build everything else but this test).

Comment 16

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Here's the problem on my machine

$ diff -u 4.2/string 4.4/string 
--- 4.2/string	2009-01-10 13:33:28.000000000 -0600
+++ 4.4/string	2010-01-10 10:47:33.000000000 -0600
[snip]
@@ -15,19 +15,14 @@
[snip]
 #ifndef _GLIBCXX_EXPORT_TEMPLATE
-# include <algorithm> // for find_if
 # include <bits/basic_string.tcc> 
 #endif

gcc 4.2 <string> includes <algorithm>, but 4.4 doesn't.  Don't ask me why this isn't a problem on linux x86, because I don't know; it certainly should have been.  Bug 551254 comment 47 is the right fix.

Comment 17

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Attachment: Don't use STL wrappers for testplugin

Comment 18

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

http://hg.mozilla.org/mozilla-central/rev/2676cf045c73

Comment 19

[Serge Gautherie (:sgautherie)]

V.Fixed, per tinderbox.

Comment 20

[Karsten Düsterloh]

Yep, working again.