OpenVMS build -> GNV: General Changes

RESOLVED FIXED

Status

SeaMonkey
Build Config
RESOLVED FIXED
15 years ago
13 years ago

People

(Reporter: Colin Blake, Assigned: Colin Blake)

Tracking

Trunk
DEC
OpenVMS

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

15.35 KB, patch
hacker formerly known as seawood@netscape.com
: review+
Details | Diff | Splinter Review
(Assignee)

Description

15 years ago
This bug report will track the general build changes with the "move OpenVMS
build to GNV" work (meta bug 180288).
(Assignee)

Comment 1

15 years ago
Created attachment 106352 [details] [diff] [review]
General build changes

These are the general build changes.
(Assignee)

Comment 2

15 years ago
config/OpenVMS.mk is no longer used. Chris, how do I go about removing this?
(Assignee)

Comment 3

15 years ago
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?
(Assignee)

Updated

15 years ago
Depends on: 180293
(Assignee)

Updated

15 years ago
No longer depends on: 180293
(Assignee)

Comment 4

15 years ago
Chris, could you review this please.
Keywords: 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.
(Assignee)

Comment 6

15 years ago
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.
(Assignee)

Comment 8

15 years ago
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.
(Assignee)

Comment 10

15 years ago
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. 
(Assignee)

Comment 12

15 years ago
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.
(Assignee)

Comment 13

15 years ago
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
(Assignee)

Updated

15 years ago
Attachment #108865 - Flags: review?(seawood)
(Assignee)

Updated

15 years ago
Attachment #108865 - Flags: approval1.3a?
Comment on attachment 108865 [details] [diff] [review]
Updated patch

r=cls
Attachment #108865 - Flags: review?(seawood) → review+
(Assignee)

Comment 15

15 years ago
Checked in to trunk.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 16

15 years ago
Comment on attachment 108865 [details] [diff] [review]
Updated patch

1.3a is complete. not taking further patches.
Attachment #108865 - Flags: approval1.3a? → approval1.3a-
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.