Closed Bug 122 Opened 27 years ago Closed 21 years ago

BUILD: Mozilla does not compile on NetBSD.

Categories

(MozillaClassic Graveyard :: XFE, defect, P3)

Other
NetBSD
defect

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.
Assignee: nobody → ramiro
Component: XFE
Lots of openbsd, netbsd code went into mozilla recently. Are there any other changes that are needed ?
Summary: Mozilla does not compile on NetBSD. → BUILD: Mozilla does not compile on NetBSD.
Adding BUILD prefix.
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.
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
Assignee: briano → wtc
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....
Status: NEW → ASSIGNED
NSPR is in v3.0 release code freeze right now. I will merge the patch after the release date (Sept. 30).
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.
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.
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.
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?
I have checked in the netlib related changes.
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 :-)
I checked in the -R$(LIBRUNPATH) change to nsprpub/config/NetBSD.mk on the main trunk and the NSPRPUB_RELEASE_3_0_BRANCH.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
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).
Status: RESOLVED → CLOSED
Closed the bug.
Setting correct OS field.
OS: other → NetBSD
Status CLOSED is deprecated as per bug 169885
Status: CLOSED → REOPENED
Resolution: FIXED → ---
Status CLOSED is deprecated as per bug 169885
Re-resolving
Status: REOPENED → RESOLVED
Closed: 26 years ago21 years ago
Resolution: --- → FIXED
verifying former CLOSED bugs
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.