Build fails on OpenBSD 3.1 / powerpc (Apple G4)

RESOLVED WONTFIX

Status

RESOLVED WONTFIX
17 years ago
14 years ago

People

(Reporter: mats, Assigned: leaf)

Tracking

Trunk
PowerPC
OpenBSD

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
Build fails on OpenBSD 3.1 / powerpc (Apple G4).

First problem is that "-Wl," is prepended to some options to ld.
For example "-Wl,--whole-archive" should have been "--whole-archive" below:

/usr/bin/ld -Bshareable /usr/lib/c++rt0.o -o libxpcom.so.1.0  nsXPComInit.o    
        -Wl,--whole-archive ../../dist/lib/libxpcomds_s.a
../../dist/lib/libxpcomio_s.a ../../dist/lib/libxpcomcomponents_s.a
../../dist/lib/libxpcomthreads_s.a ../../dist/lib/libxpcomproxy_s.a
../../dist/lib/libxpcombase_s.a ../../dist/lib/libxptcall.a
../../dist/lib/libxptinfo.a ../../dist/lib/libxpt.a ../../dist/lib/libxptcmd.a
../../dist/lib/libmozreg_s.a ../../dist/lib/libstring_s.a
../../dist/lib/libstring_obsolete_s.a ../../dist/lib/libxpcomglue_s.a 
-Wl,--no-whole-archive  -L/usr/mats/mozilla/dist/lib -lplds4 -lplc4 -lnspr4  -lm
/usr/bin/ld: unrecognized option `-Wl,--whole-archive'
/usr/bin/ld: use the --help option for usage information
gmake[3]: *** [libxpcom.so.1.0] Error 1
gmake[3]: Leaving directory `/usr/mats/mozilla/xpcom/build'


I also saw the same for "-Wl,-E" at other places.

After linking manually where this occured I finally made it to:

/usr/bin/ld -Bshareable /usr/lib/c++rt0.o -o libgkcontent.so.1.0  nsContentDLF.o
nsContentModule.o nsContentHTTPStartup.o
    --whole-archive ../../dist/lib/libgkconevents_s.a
../../dist/lib/libgkconhtmlcon_s.a ../../dist/lib/libgkconhtmldoc_s.a
../../dist/lib/libgkconhtmlstyle_s.a ../../dist/lib/libgkconxmlcon_s.a
../../dist/lib/libgkconxmldoc_s.a ../../dist/lib/libgkconxsldoc_s.a
../../dist/lib/libgkconxulcon_s.a ../../dist/lib/libgkconxuldoc_s.a
../../dist/lib/libgkconxultmpl_s.a ../../dist/lib/libgkconxbl_s.a
../../dist/lib/libgkconbase_s.a ../../dist/lib/libgkconshared_s.a 
--no-whole-archive -L../../dist/bin -L../../dist/lib -lgkgfx -L../../dist/bin
-lxpcom -L../../dist/bin -L/usr/mats/mozilla/dist/lib -lplds4 -lplc4 -lnspr4 
../../dist/lib/libunicharutil_s.a -L../../dist/bin -lmozjs   -lm
ld in free(): warning: modified (page-) pointer.
ld in free(): warning: modified (page-) pointer.
../../dist/lib/libgkconbase_s.a: object
../../dist/lib/libgkconbase_s.a(nsRange.o) in archive is not object
gmake[3]: *** [libgkcontent.so.1.0] Error 1


Where I gave up.
(OpenBSD 3.1/powerpc probably isnt a supported platform, but I thought
I should let you know anyway).

g4> ld -v
GNU ld version 2.10.1 (with BFD 2.10.1)
g4> gcc -v
Reading specs from /usr/lib/gcc-lib/powerpc-unknown-openbsd3.1/2.95.3/specs
gcc version 2.95.3 20010125 (prerelease)

I was building a Mozilla trunk tar-ball from May 19, 2002
Try the patch from bug 124958 which uses gcc instead of ld to link shared libs.  
Depends on: 124958
Oh, and the nsRange.o looks like a corrupt file.  Try removing it and rebuilding.
Priority: -- → P4
Target Milestone: --- → mozilla1.2beta
(Reporter)

Comment 3

17 years ago
Thanks for your help.

The nsRange.o problem was just the linking process that hit the per process
memory limit. "ulimit -d unlimited" fixed that.

After applying the suggested configure.in patch the build went fine.
(though I was amazed by the volume of compiler warnings ;)

Both mozilla and viewer crashed with this error message:

# ./run-mozilla.sh ./viewer
Type Manifest File: /usr/mats/mozilla/dist/bin/components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
./viewer: ./libldap50.so.1.0 :can't resolve reference 're_comp'
Memory fault (core dumped)
#

and GDB says:
(gdb) bt
#0  0x218740e8 in ?? () from /usr/libexec/ld.so
Cannot access memory at address 0xffffd740.
(gdb) 
Ah. That problem is because the ldap openbsd changes from bug  145136 are
incomplete.  I'll attach an updated patch there.
(Reporter)

Comment 5

17 years ago
Tried the patch from bug 145136 (which gave me -llber50 -lc_r to linkage of
libldap) but that didn't help. It still couldn't resolve "re_comp".

Howvere, the man-page for re_comp said:
     This interface is made obsolete by regex(3). It is available from the
     compatibility library, libcompat.

So I added -lcompat instead and that fixed the "re_comp" problem:

> ./run-mozilla.sh ./viewer
Type Manifest File: /usr/mats/mozilla/dist/bin/components/xpti.dat
nsNativeComponentLoader: autoregistering begins.
nsNativeComponentLoader: autoregistering succeeded
nNCL: registering deferred (0)
Unable to instantiate Cookie Manager
WARNING: NS_ENSURE_TRUE(mWindow) failed, file nsBrowserWindow.cpp, line 377
Memory fault (core dumped)

and GDB says:

#0  nsWebCrawler::GetBrowserWindow (this=0x0, aWindow=0xffffe268) at
nsWebCrawler.cpp:859
859       NS_IF_ADDREF(mBrowser);
(gdb) bt
#0  nsWebCrawler::GetBrowserWindow (this=0x0, aWindow=0xffffe268) at
nsWebCrawler.cpp:859
#1  0x1836b08 in nsViewerApp::OpenWindow (this=0x188ed80) at nsViewerApp.cpp:654
#2  0x1843520 in nsNativeViewerApp::Run (this=0x188ed80) at nsGtkMain.cpp:66
#3  0x1843a34 in main (argc=1, argv=0xffffe614) at nsGtkMain.cpp:195
#4  0x181a4dc in _start ()
(gdb)


PS.
I tried linking libldap with both:
... -lcompat
... -llber50 -lc_r -lcompat
and got the same crash above so I'm not so sure that the patch in bug 145136
is really needed for OpenBSD.
It's definitely needed  for  x86 OpenBSD.  The PPC port must have other issues.
 That last stack trace is unrelated to the ldap changes.  We see something
similiar with the x86 port.
Target Milestone: mozilla1.2beta → Future
still happening with never version(s)?
(bug cleaning)
(Reporter)

Comment 8

16 years ago
Yes, the build problems are pretty much the same using Mozilla 1.3b source.
I was able to build it only after changing ld->gcc for linking shared libs...

The results when starting mozilla:
WARNING: gre: XPCOMGlueStartup failed, file nsXPCOMGlue.cpp, line 227
WARNING: GRE_Startup failed, file nsAppRunner.cpp, line 1576

then the process exit(1), no core dump.
Mass reassign to new default build assignee
Assignee: seawood → mozbugs-build
Priority: P4 → --
Mass reassign of Build/Config bugs to Leaf.
Assignee: mozbugs-build → leaf
Target Milestone: Future → ---
(Reporter)

Comment 11

15 years ago
Since OpenBSD 3.1 is not maintained by OpenBSD.org any longer (~1 year now)
I see no reason to keep this bug open.
(OpenBSD 3.4 will be fixed by bug 236599.)
(Reporter)

Comment 12

15 years ago
OpenBSD 3.1 is not maintained by OpenBSD.org since a long time ...
(see bug 236599 for patches for newer OpenBSD versions)

-> WONTFIX
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WONTFIX
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.