Closed Bug 352822 Opened 13 years ago Closed 7 years ago

apps since MOZILLA_1_8_BRANCH don't build anymore on FreeBSD

Categories

(Firefox Build System :: General, defect)

All
FreeBSD
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: juergenherz, Unassigned)

References

Details

(Keywords: meta, Whiteboard: [not needed for 1.9])

Attachments

(4 files, 2 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.6) Gecko/20060904 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.8.0.6) Gecko/20060904 Firefox/1.5.0.6

I'm unable to build Firefox or Seamonkey from HEAD or MOZILLA_1_8_BRANCH on a FreeBSD 6.1 system: undefined references to strncmp, malloc and other standard functions.

Build failure looks as follows:
gcc -I/usr/X11R6/include  -I/usr/X11R6/include -Wall -W -Wno-unused
-Wpointer-arith -Wcast-align -Wno-long-long -pedantic -pipe  -DDEBUG -D_DEBUG -DDEBUG_jrg -DTRACING -g -fPIC -shared -Wl,-z,defs -Wl,-h,libmozjs.so -o libmozjs.so  jsapi.o jsarena.o jsarray.o jsatom.o jsbool.o jscntxt.o jsdate.o jsdbgapi.o jsdhash.o jsdtoa.o jsemit.o jsexn.o jsfun.o jsgc.o jshash.o jsinterp.o jsiter.o jslock.o jslog2.o jslong.o jsmath.o jsnum.o jsobj.o jsopcode.o jsparse.o
jsprf.o jsregexp.o jsscan.o jsscope.o jsscript.o jsstr.o jsutil.o jsxdrapi.o jsxml.o prmjtime.o    -pthread -lm -pthread -L../../dist/lib -lplds4 -lplc4 -lnspr4 -pthread -lm
jsapi.o(.text+0xaf): In function `TryArgumentFormatter':
/usr/home/jrg/mozilla/js/src/jsapi.c:144: undefined reference to `strncmp'
jsapi.o(.text+0x5db): In function `__maskrune':
/usr/include/_ctype.h:101: undefined reference to `___runetype'
jsapi.o(.text+0x5ef):/usr/include/_ctype.h:101: undefined reference to
`_CurrentRuneLocale'
jsapi.o(.text+0xa32): In function `JS_AddArgumentFormatter':
/usr/home/jrg/mozilla/js/src/jsapi.c:414: undefined reference to `strlen'
jsapi.o(.text+0xa77):/usr/home/jrg/mozilla/js/src/jsapi.c:420: undefined
reference to `strcmp'
jsapi.o(.text+0xb0a): In function `JS_RemoveArgumentFormatter':
a.s.o

Apps from MOZILLA_1_8_0_BRANCH build ok. Comparing both linker statements, it shows "-Wl,-z,defs" is new in the not working builds.

After just adding -lc to the the LDFLAGS for FreeBSD, compiling worked for MOZILLA_1_8_BRANCH branch. Alternatively removing "-Wl,-z,defs" from DSO_LDOPTS led to the same result.

So from my point of view "-Wl,-z,defs" causes (gcc/ld on) FreeBSD not to find libc anymore. I'm using GCC 3.4.4, gmake 3.80 and autoconf 2.13.

Reproducible: Always
Confirming for FreeBSD-STABLE. I remember having seen some
bug dealing with the same issue on Solaris some time ago.

Juergen, the options you mentioned are actually passed to
the linker and cause it to not allow undefined symbols in
objects (though they may still be allowed in shared libs).
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #1)
> Juergen, the options you mentioned are actually passed to
> the linker and cause it to not allow undefined symbols in
> objects (though they may still be allowed in shared libs).

That's right, I've found that out afterwards.
Those symbols aren't found, but it seems that doesn't matter. In contrast to Linux binaries, ldd doesn't report libc or libpthread for libmozjs.so (neither for my build without -z defs, nor for the official FreeBSD packages of SM 1.0x or FF 1.5), but works nevertheless.
I don't know what all that means, I only know that the current build code makes it impossible to build on FreeBSD out of the box.
Attached patch wipSplinter Review
FWIW, the changes I did to compile Firefox trunk on FreeBSD 6.2-RC1/i386.
The file "stdint.h" is not available on FreeBSD 4.x, only "inttypes.h" is available on certain systems including BeOS, OpenBSD.
On FreeBSD (at least 4.x), using "-lc" in LDFLAGS results in "rcmdsh: unknown user".

I've had successful builds for Firefox and Thunderbird with using "-lc_r".
Post from my weblog on building Firefox/Thunderbird on FreeBSD 4.x:
http://gopalarathnam.com/weblog/2007/02/07/building-firefoxthunderbird-20-on-freebsd-4x.html
Attachment #254655 - Flags: review?(vladimir)
(In reply to comment #5)
> On FreeBSD (at least 4.x), using "-lc" in LDFLAGS results in "rcmdsh: unknown
> user".
> I've had successful builds for Firefox and Thunderbird with using "-lc_r".

On FreeBSD 4.x I presume.  This bug is about build problems on FreeBSD 6.2
or newer.  FreeBSD 4.11 reached end-of-life on February 1, 2007.
http://groups.google.com/group/mailing.freebsd.announce/browse_thread/thread/eaffc8c58bd9cc6a/c0585d8c62fabcbf?lnk=st&rnum=1&hl=en#c0585d8c62fabcbf
There are a few patches required to get this to build. Been using 3.0b2 on FreeBSD 6.2 today(submitted the patches using it) and not seeing any bugs yet. There are definite performance improvements over Firefox 2.0

I have static i386 builds if anyone is interested in testing...
Attachment #295549 - Flags: review?(steve
Attachment #295549 - Flags: review?(ryan)
Attachment #295549 - Flags: review?(mediagirl.tech)
Attachment #295549 - Flags: review?(matt)
Attachment #295549 - Flags: review?(kevin)
Attachment #295549 - Flags: review?(jay.weber)
Attachment #295549 - Flags: review?(is-anyone)
Attachment #295549 - Flags: review?(anil.gursahani)
Attachment #295549 - Flags: review?(jay.weber) → review?
Attachment #295549 - Flags: review?(steve)
Attachment #295549 - Flags: review?(ryan)
Attachment #295549 - Flags: review?(mediagirl.tech)
Attachment #295549 - Flags: review?(matt)
Attachment #295549 - Flags: review?
(In reply to comment #8)
> Created an attachment (id=295549) [details]
> Patches to build firefox 3.0b2 on FreeBSD 6.2
> 
> There are a few patches required to get this to build. Been using 3.0b2 on
> FreeBSD 6.2 today(submitted the patches using it) and not seeing any bugs yet.
> There are definite performance improvements over Firefox 2.0

Please make all patches against trunk CVS and submit them/it for review (not in a tarball, please).
Attachment #295549 - Attachment is obsolete: true
Attachment #295549 - Flags: review?(kevin)
Attachment #295549 - Flags: review?(is-anyone)
Attachment #295549 - Flags: review?(anil.gursahani)
Attached patch config_autoconf.mk.in.patch (obsolete) — Splinter Review
Attachment #295563 - Flags: review?
Attachment #295564 - Flags: review?
> Please make all patches against trunk CVS and submit them/it for review (not in
> a tarball, please).
> 

No problem. Added the patch files separately.
More info on the build steps are here --> http://jng.imagine27.com/pages/buildfirefox30b2
Attachment #295566 - Flags: review? → review?(wtc)
Attachment #295564 - Flags: review? → review?(jonas)
Attachment #295564 - Flags: superreview?(jonas)
Attachment #295563 - Flags: review? → review?(benjamin)
When running 'gmake package' it fails:

... SNIP ...

Linking .xpt files...
[browser]
Linking .xpt files completed.
Stripping package directory...
signing nss libraries
Fatal error 'Spinlock called when not threaded.' at line 87 in file /usr/src/lib/libpthread/thread/thr_spinlock.c (errno = 0)
Abort trap (core dumped)
Fatal error 'Spinlock called when not threaded.' at line 87 in file /usr/src/lib/libpthread/thread/thr_spinlock.c (errno = 0)
Abort trap (core dumped)
Removing unpackaged files...
cd ../../dist/firefox; rm -rf firefox-config firefox-bin.elf regchrome* regxpcom* xpcshell* xpidl* xpt_dump* xpt_link*  core bsdecho gtscc jscpucfg nsinstall viewer TestGtkEmbed bloaturls.txt codesighs* elf-dynstr-gc mangle* maptsv* mfc* mkdepend* msdump* msmap* nm2tsv* nsinstall* rebasedlls* res/samples res/throbber shlibsign* winEmbed.exe os2Embed.exe chrome/chrome.rdf chrome/app-chrome.manifest chrome/overlayinfo components/compreg.dat components/xpti.dat content_unit_tests necko_unit_tests 
/usr/home/jgrant/build/mozilla/firefox-3.0b2-en-US.freebsd62-i386-static/config/nsinstall -t removed-files ../../dist/firefox
Compressing...
cd ../../dist && gtar -c --owner=0 --group=0 --numeric-owner --mode="go-w" -f - firefox | bzip2 -vf > firefox-3.0b2.en-US.freebsd6.2-i386.tar.bz2
  (stdin): 

I had a similar bug which also related to signing the libs which I fixed to get the source to build. This seems like it may be the same issue.
Attachment #295564 - Flags: superreview?(jonas)
Attachment #295564 - Flags: superreview+
Attachment #295564 - Flags: review?(jonas)
Attachment #295564 - Flags: review+
Attachment #295564 - Flags: approval1.9?
Comment on attachment 295563 [details] [diff] [review]
config_autoconf.mk.in.patch

I'm not sure it's a good idea to specify the libs directly in autoconf.mk.in (especially when those entries are valid for all platforms).
Shouldn't we specify those things in config/rules.mk instead?
(see Mats' approach in the first patch)
(In reply to comment #14)
This seems to be caused by a conflict of multiple threading libs being used
simultaneously. I was able to work around the problem by adding the following
two lines to etc/libmap.conf (but it's more of an ugly hack):
 libc_r.so.6       libthr.so
 libpthread.so.2   libthr.so

I'm not sure how to solve the problem from within our codebase. Justin, was
security_nss_cmd_shlibsign_sign.sh.patch meant to tackle this specific problem?
Comment on attachment 295566 [details] [diff] [review]
security_nss_cmd_shlibsign_sign.sh.patch

This change to sign.sh is a workaround that masks the real problem.
This patch causes us to run shlibsign with the system NSS libraries.
But we want to run shlibsign with the NSS libraries we just built.
Why can't we run shlibsign with LD_LIBRARY_PATH set?
Attachment #295566 - Flags: review?(wtc) → review-
Attachment #295563 - Attachment is obsolete: true
Attachment #295563 - Flags: review?(benjamin)
(In reply to comment #15)
> (From update of attachment 295563 [details] [diff] [review])
> I'm not sure it's a good idea to specify the libs directly in autoconf.mk.in
> (especially when those entries are valid for all platforms).
> Shouldn't we specify those things in config/rules.mk instead?
> (see Mats' approach in the first patch)
> 

Marco, you're right please go with the previous patch instead.
Using the FreeBSD official port patches might help.
Take a look at /usr/ports/www/firefox/files on your FreeBSD system.
(In reply to comment #17)
> (From update of attachment 295566 [details] [diff] [review])
> This change to sign.sh is a workaround that masks the real problem.
> This patch causes us to run shlibsign with the system NSS libraries.
> But we want to run shlibsign with the NSS libraries we just built.
> Why can't we run shlibsign with LD_LIBRARY_PATH set?
> 

Take a look at /usr/ports/www/firefox/files/patch-sysnss
(In reply to comment #20)

Justin, I don't have a FreeBSD system, but I was able to find
the source of /usr/ports/www/firefox/files/patch-sysnss at
http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/firefox/files/patch-sysnss

It is a patch for building Firefox using system NSS.  It doesn't
contain any patch for NSS itself.  So it doesn't answer my question
in comment 17 regarding your NSS patch (attachment 295566 [details] [diff] [review]).
I found the patches for NSS itself in
http://www.freebsd.org/cgi/cvsweb.cgi/ports/security/nss/files/

but I don't see any patch related to your NSS patch (attachment 295566 [details] [diff] [review]).
(In reply to comment #17)
> (From update of attachment 295566 [details] [diff] [review])
> This change to sign.sh is a workaround that masks the real problem.
> This patch causes us to run shlibsign with the system NSS libraries.
> But we want to run shlibsign with the NSS libraries we just built.
> Why can't we run shlibsign with LD_LIBRARY_PATH set?
> 

I don't see any reason why we can't run shlibsign the way you suggest using LD_LIBRARY_PATH set. I will play with it some more...

(In reply to comment #21)
> (In reply to comment #20)
> 
> Justin, I don't have a FreeBSD system, but I was able to find
> the source of /usr/ports/www/firefox/files/patch-sysnss at
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/www/firefox/files/patch-sysnss
> 
> It is a patch for building Firefox using system NSS.  It doesn't
> contain any patch for NSS itself.  So it doesn't answer my question
> in comment 17 regarding your NSS patch (attachment 295566 [details] [diff] [review]).
> 

Actually patch-sysnss looks like it does contain the patch to use the supplied NSS. Although with the 3.0b2 source it looks like you are right and LD_LIBRARY_PATH would still need to be set correctly.

I just confirmed this. Using patch-sysnss causes the signing to fail and libssl.so.3, libssl3.so and libsmime3.so etc. are reported missing. This means the patched version is trying to use the mozilla NSS libraries as these versions are not part of the FreeBSD nss system install.
Attachment #295564 - Flags: approval1.9? → approval1.9+
Comment on attachment 295564 [details] [diff] [review]
content_xslt_public_txDouble.h.patch

Checking in content/xslt/public/txDouble.h;
/cvsroot/mozilla/content/xslt/public/txDouble.h,v  <--  txDouble.h
new revision: 1.2; previous revision: 1.1
done
Whiteboard: [not needed for 1.9]
To all that aren't able to compile Firefox 3.0 on FreeBSD,

I downloaded the Firefox 3.0.1 port from the ports tree here
http://cvsweb.freebsd.org/ports/www/firefox3/firefox3.tar.gz?tarball=1
and then created the .mozconfig file (contents of which are below) in my home directory and compiled it with only one problem.

It complained "can't cd to" the directory where it extracts the downloaded firefox 3 source code.

1) I then cd'd into the work directory and ran:
2) mv mozilla firefox-3.0.1-source
3) After which I cd'd back into its parent directory and ran make install.

.mozconfig contents
ac_add_options --enable-extensions=default
ac_add_options --enable-optimize="-O2"
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --disable-debug
ac_add_options --enable-official-branding
ac_add_options --prefix=/usr/local/share/firefox-3.0.1
ac_add_options --disable-tests
mk_add_options MOZ_CURRENT_PROJECT=browser
ac_add_options --enable-application=browser

Regards
Greg
On FreeBSD 7 (at least for i386) the Mozilla apps (tested on trunk) seem to
build quite nicely when disabling (or patching) the following parts:

* <audio>/<video> support (see bug 449066)
  (--disable-ogg and --disable-wave)

* ldap support (see bug 449453)
  (--disable-ldap)

* tests (probably several scattered bugs)
  (--disable-tests)
Depends on: 449453, 449066
Depends on: 487754, 488168
Comment on attachment 254655 [details] [diff] [review]
Patch for cairo (pixman.h) for building on FreeBSD 4.x

Dunno if this is still needed, but it should go into upstream libpixman
Current trunk code may require the following lines in the mozconfig file
in order to build on FreeBSD:

ac_add_options --disable-necko-wifi
ac_add_options --disable-updater
Severity: major → normal
Keywords: meta
Hardware: x86 → All
Depends on: 506079
Depends on: 544377
Depends on: 550666
Depends on: 558576
Depends on: 557000
No longer depends on: 558576
Depends on: 750447
Is this still an issue with supported FreeBSD releases (8.x and 9.x currently)?

Try building mozilla-central checkout with bug 753046 applied

  # my .mozconfig on 10.0-CURRENT amd64
  ac_add_options --with-system-libevent=/usr/local
  ac_add_options --disable-necko-wifi
  ac_add_options --disable-libnotify
  ac_add_options --disable-dbus

Regarding bundled libevent, fixing it is a waste of time:
- based on obsolete libevent14 branch
- likely needs FreeBSD patches from devel/libevent port
It is, but attachment 647924 [details] [diff] [review] seems to fix it, at least on FreeBSD 9-Stable (amd64).
Trunk builds again on FreeBSD, at least with clang (instead of gcc).
Jan's options from comment 30 should be used in mozconfig though.
Another working mozconfig for FreeBSD 9-stable (amd64):

CC=clang;      export CC
CXX=clang++;   export CXX
CPP=clang-cpp; export CPP
ac_add_options --disable-necko-wifi
ac_add_options --with-system-libevent=/usr/local
#ac_add_options --disable-tests
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.