180290 - OpenVMS build -> GNV: General Changes

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Colin Blake]

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

Comment 1

[Colin Blake]

Attachment: General build changes

These are the general build changes.

Comment 2

[Colin Blake]

config/OpenVMS.mk is no longer used. Chris, how do I go about removing this?

Comment 3

[Colin Blake]

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?

Comment 4

[Colin Blake]

Chris, could you review this please.

Comment 5

[hacker formerly known as [e-mail]]

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.

Comment 6

[Colin Blake]

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? 

Comment 7

[hacker formerly known as [e-mail]]

Looks like an oversight.  HOST_PROGRAM should be using HOST_LDFLAGS which will
default to LDFLAGS if HOST_LDFLAGS is not specified.

Comment 8

[Colin Blake]

Cool. Do you want me to include the fix as part of this checkin, or are you
going to fix it separately?

Comment 9

[hacker formerly known as [e-mail]]

Fix it here otherwise it won't get fixed until post 1.3a.

Comment 10

[Colin Blake]

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.

Comment 11

[hacker formerly known as [e-mail]]

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. 

Comment 12

[Colin Blake]

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.

Comment 13

[Colin Blake]

Attachment: Updated patch

Changes from previous patch:
  - Defines HOST_LDFLAGS in HOST_PROGRAM rule
  - Corrects an incorrectly places #endif in previous edit of nsinstall.c

Comment 14

[hacker formerly known as [e-mail]]

Comment on attachment 108865 [details] [diff] [review]
Updated patch

r=cls

Comment 15

[Colin Blake]

Checked in to trunk.

Comment 16

[Asa Dotzler [:asa]]

Comment on attachment 108865 [details] [diff] [review]
Updated patch

1.3a is complete. not taking further patches.