This bug report will track the general build changes with the "move OpenVMS build to GNV" work (meta bug 180288).
Created attachment 106352 [details] [diff] [review] General build changes These are the general build changes.
config/OpenVMS.mk is no longer used. Chris, how do I go about removing this?
I also have five new files which reside in a new directory: build/unix/vms build/unix/vms/mozilla.com build/unix/vms/install.com build/unix/vms/getinfo.com build/unix/vms/libxpcom_symvec.opt build/unix/vms/component_symvec.opt Chris, should I just post these files as attachments for review? Is there any other work involved in adding new directories and files to the repository?
Chris, could you review this please.
Attachment #106352 - Flags: review+
To remove a file: rm foo cvs rm foo cvs ci foo Since the files are vms specific, the best I could do is rubberstamp them. :) I believe you have to 'cvs add' the empty directory first, but that should be the trickiest part of adding a new directory.
Bit rot has set in. I've been bitten by the change to the way nsinstall is now built as a HOST_PROGRAM. I don't define HOST_* symbols for OpenVMS, and so HOST_CC ends up being the same as CC. This means that some OpenVMS Porting Library stuff gets sucked in to the compile, but at link time it can't find the Porting Library routines. Why not? Because they are usually brought in to the link via LDFLAGS, an for a HOST_PROGRAM we don't include LDFLAGS. Arghh. Looks like HOST_LIBS is used instead. Is that where I should replicate the LDFLAGS stuff?
Looks like an oversight. HOST_PROGRAM should be using HOST_LDFLAGS which will default to LDFLAGS if HOST_LDFLAGS is not specified.
Cool. Do you want me to include the fix as part of this checkin, or are you going to fix it separately?
Fix it here otherwise it won't get fixed until post 1.3a.
Where should the fix go in? In rules.mk include HOST_LDFLAGS (with HOST_LIBS) in the HOST_PROGRAM rule? That's a generic change and I can't test that on other platforms. I don't want to break the build tonight!! Plus I don't think I'll be getting this in until after 1.3a now anyways, because I'm waiting on 180293/4.
Yes, that's the proper place. That change shouldn't affect our standard builds since they don't set LDFLAGS and I doubt anyone is depending upon the current buggy behavior.
Doesn't work. Looks like HOST_LDFLAGS is only set if in configure if we're cross-compiling (target != host): http://lxr.mozilla.org/seamonkey/source/nsprpub/configure.in#373 For now I can set HOST_LDFLAGS manually in my environment, but I think we need a better solution.
Created attachment 108865 [details] [diff] [review] Updated patch Changes from previous patch: - Defines HOST_LDFLAGS in HOST_PROGRAM rule - Corrects an incorrectly places #endif in previous edit of nsinstall.c
Attachment #106352 - Attachment is obsolete: true
Comment on attachment 108865 [details] [diff] [review] Updated patch r=cls
Attachment #108865 - Flags: review?(seawood) → review+
Checked in to trunk.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Comment on attachment 108865 [details] [diff] [review] Updated patch 1.3a is complete. not taking further patches.
Attachment #108865 - Flags: approval1.3a? → approval1.3a-
You need to log in before you can comment on or make changes to this bug.