Closed
Bug 122
Opened 27 years ago
Closed 21 years ago
BUILD: Mozilla does not compile on NetBSD.
Categories
(MozillaClassic Graveyard :: XFE, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: frank, Assigned: wtc)
References
()
Details
Created by Frank van der Linden (frank@wins.uva.nl) on Wednesday, April 8, 1998 3:46:34 PM PDT
Additional Details :
Mozilla does not compile on NetBSD. I made it compile and
run on NetBSD/i386. The diffs are at:
ftp://ftp.netbsd.org/pub/NetBSD/misc/fvdl/mozilla/diff.001
These diffs mainly deal with getting things to work on
NetBSD. This first patch is only tested for the i386
platform, other platforms may need some small modifications
in the MD parts of the code, so more diffs are likely to
follow. I also split out some of the *BSD defines, to not
make them depend on eachother.
In further bugreports for NetBSD, I will probably be using
the directory mentioned above to make the patches available
to you.
- Frank
P.S.
I selected the "PC" platform because it allowed me to
specify the "other" category :-) But it is by no means
the only NetBSD platform.
Updated by Wan-Teh Chang (wtc@netscape.com) on Wednesday, April 22, 1998 12:58:23 PM PDT
Additional Details :
Added myself to the CC list.
I will look at the diffs concerning ns/nsprpub.
Updated by Frank van der Linden (frank@wins.uva.nl) on Sunday, May 24, 1998 4:43:14 PM PDT
Additional Details :
The updated changes for the 1998-04-29 version can be found in
ftp://ftp.netbsd.org/ftp/pub/NetBSD/misc/fvdl/mozilla/diff-19980429.001
There weren't many changes; just a few conflicts with changes made in the main
source tree were resolved.
Updated by Frank van der Linden (frank@wins.uva.nl) on Sunday, May 24, 1998 4:45:42 PM PDT
Additional Details :
Just to be a bit clearer, I updated the version & platform in the bugreport
(I hope the update for that works in bugzilla)
Updated by Frank van der Linden (frank@wins.uva.nl) on Tuesday, August 4, 1998 12:02:11 PM PDT
Additional Details :
The remainder of the patches (i.e. the ones that are left now that the nsprpub
part has been integrated) for the 1998-07-28 release can be found in
ftp://ftp.netbsd.org/pub/NetBSD/misc/fvdl/mozilla/diff-19980728.001
This diff does contain 2 additions to files that already were patched; one
because the name of a jmpbuf index was changed in the arm32 specific files
of NetBSD, and another that makes the compile always use -fPIC.
Updated•27 years ago
|
Assignee: nobody → ramiro
Component: XFE
Lots of openbsd, netbsd code went into mozilla recently. Are there any other
changes that are needed ?
Updated•27 years ago
|
Summary: Mozilla does not compile on NetBSD. → BUILD: Mozilla does not compile on NetBSD.
Reporter | ||
Comment 3•27 years ago
|
||
I have put the diffs that were not yet applied split by module in
ftp://ftp.netbsd.org:/ftp/pub/NetBSD/misc/fvdl/mozilla/split/
Note that these diffs are against an older version, so the lines will be off
by a bit. But they should still apply.
The ones that are certainly needed to avoid build problems on some platforms
are:
config.diff
nspr.diff
The others are sometimes just cosmetical. The scheduler diff may be needed as
well, I can't check right now. It takes care of a problem caused by the extra
space at the end of the module/libnames in the Makefile.
Adding wtc@netscape.com and briano@netscape.com since they own nspr and config
respectively.
Updated•26 years ago
|
Assignee: ramiro → briano
I think the xfe code has been checked in. Either briano@netscape.com or
wtc@netscape.com should own this bug now until they check in the needed code
into config and nspr.
Reassign to briano@netscape.com
Updated•26 years ago
|
Assignee: briano → wtc
Comment 6•26 years ago
|
||
The config changes are now in. Reassigning to Wan-Teh.
FYI: I have an extremely flaky Amiga running 1.3.1. As soon as it's
running properly, I'll finally be able to do test builds. If anyone
cares....
Assignee | ||
Updated•26 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 7•26 years ago
|
||
NSPR is in v3.0 release code freeze right now.
I will merge the patch after the release date
(Sept. 30).
Assignee | ||
Comment 8•26 years ago
|
||
I didn't realize the patch was so small. So
I decided to check it in.
mozilla/nsprpub/pr/include/md/_netbsd.h, revision 3.2.
Who's next? Frank, can you verify that all your patches
have been checked in? Thanks.
Reporter | ||
Comment 9•26 years ago
|
||
All the past patches to make it compile out of the box have been integrated,
thanks guys. However, when I compiled 19981008 and beyond (my last cvs update
was on 19981109), I needed few more changes to make it compile. These additional
patches are small, a total of 120 lines of context diff.
You can find the whole patch in:
ftp://ftp.netbsd.org/pub/NetBSD/misc/fvdl/mozilla/diff-19981008.001
Or, split by category, in the URL already associated with this bugreport.
The applicable categories are config, network, nspr and xfe.
If these patches are applied, both 122 and 263 can be closed.
Reporter | ||
Comment 10•26 years ago
|
||
All the past patches to make it compile out of the box have been integrated,
thanks guys. However, when I compiled 19981008 and beyond (my last cvs update
was on 19981109), I needed few more changes to make it compile. These additional
patches are small, a total of 120 lines of context diff.
You can find the whole patch in:
ftp://ftp.netbsd.org/pub/NetBSD/misc/fvdl/mozilla/diff-19981008.001
Or, split by category, in the URL already associated with this bugreport.
The applicable categories are config, network, nspr and xfe.
If these patches are applied, both 122 and 263 can be closed.
Assignee | ||
Comment 11•26 years ago
|
||
Added Gagan to the cc list because the patch contains
changes to mozilla/network. Brian, Gagan, and Ramiro,
can you check in the changes to config, network, and
xfe, respectively?
I have checked in the changes to nsprpub on the main
trunk and the NSPRPUB_RELEASE_3_0_BRANCH, with the
exception of the "-R $(LIBRUNPATH)" change.
Frank, can you explain this change a little? Why
do we need to specify the -R <path> option when
building shared libraries? Seems to me that it's
only useful when building executable programs.
I am also concerned that our build system will
depend on one more environment variable. If we
really need to set -R <path>, is it possible to
determine the pathname in the makefile, as opposed
to getting it from the environment?
Comment 12•26 years ago
|
||
I have checked in the netlib related changes.
Reporter | ||
Comment 13•26 years ago
|
||
Removed Gagan from the cc-list again, because the network/ changes have been
checked in.
About -R$(LIBRUNPATH): there are a few shared libraries that link in other
shared libraries, i.e. they use -L.. -l<othersharedlib> when they are created.
This means that the other libraries will implicitly linked in, so that you
only need to link with that one shared lib. The others will be pulled in
automagically. X11 does this (well, on some systems) for libXmu and libXt.
The NetBSD dynamic linker does not find an implicitly linked in library if -R is
not specified. This could be considered a bug, I am not sure about this behavior
on other systems. I will discuss this internally. However, there we are.. -R is
needed to make it find the libraries.
This could be fixed differently, probably. You can do that by not relying on the
implicit library dependency and always link in all shared libs that you need.
I.e. do not use -L.. -l.. when creating a shared lib, but just always link in
all needed libraries. There are 2 libraries that currently have an implicit
dependency on libnspr21, I believe. I am away from my NetBSD systems right now,
but if you want I could check.
About the need for -R itself.. If you want to install the mozilla shared libs
in a non-standard place, you'll need -R. LIBRUNPATH is a way to specify this
non-standard place. It is already used in cmd/xfe/Makefile (at my request too).
Our package system (automated fetch-compile-install system for 3rd party source,
like FreeBSD has too) relies on being able to set the LIBRUNPATH env variable
to the right value for mozilla, in order to install its shared objects in
<prefix_to_X_packages>/lib/mozilla. But it's use is more general then that, I
think you need to
have a way of specifying a non-standard place for the shared objects, without
resorting to shellscripts with LD_LIBRARY_PATH, etc.
I can imagine that this is an issue for other systems too. If there is a better
way to solve this, that'd be great, but for now I think this is an ok way to do
it. If you do not define LIBRUNPATH -- normal compile as on other systems. If
you do define it, you gain some flexibility.
I hope that explains it, the description for this bug is getting rather lengthy
:-)
Assignee | ||
Comment 14•26 years ago
|
||
I checked in the -R$(LIBRUNPATH) change to nsprpub/config/NetBSD.mk
on the main trunk and the NSPRPUB_RELEASE_3_0_BRANCH.
Assignee | ||
Updated•26 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 15•26 years ago
|
||
I checked in your patch to mozilla/cmd/xfe/Makefile.
I also made the same change to mozilla/cmd/xfe/Makefile.in.
/cvsroot/mozilla/cmd/xfe/Makefile, revision 3.79.
/cvsroot/mozilla/cmd/xfe/Makefile.in, revision 3.33.
Since Brian Ostrom has already checked in the patch
for config/NetBSD.mk, I am closing this bug and bug
263 (see frank@wins.uva.nl 11/12/98 07:06).
Assignee | ||
Updated•26 years ago
|
Status: RESOLVED → CLOSED
Assignee | ||
Comment 16•26 years ago
|
||
Closed the bug.
Comment 18•21 years ago
|
||
Status CLOSED is deprecated as per bug 169885
Status: CLOSED → REOPENED
Resolution: FIXED → ---
Comment 19•21 years ago
|
||
Status CLOSED is deprecated as per bug 169885
Comment 20•21 years ago
|
||
Re-resolving
Status: REOPENED → RESOLVED
Closed: 26 years ago → 21 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•