Closed Bug 236599 Opened 20 years ago Closed 17 years ago

openbsd configuration fixes for alpha, amd64, arm, i386, macppc and sparc64

Categories

(Firefox Build System :: General, defect, P5)

1.8 Branch
All
OpenBSD
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: wilfried, Assigned: wilfried)

References

Details

(Keywords: fixed1.8.1.8)

Attachments

(11 files, 18 obsolete files)

1.21 KB, patch
dmosedale
: review+
dmosedale
: superreview+
Details | Diff | Splinter Review
1.78 KB, patch
cls
: review+
Details | Diff | Splinter Review
1.56 KB, patch
cls
: review+
Details | Diff | Splinter Review
653 bytes, patch
wtc
: review+
Details | Diff | Splinter Review
916 bytes, patch
cls
: review+
Details | Diff | Splinter Review
1.26 KB, patch
cls
: review+
Details | Diff | Splinter Review
518 bytes, patch
wtc
: review+
Details | Diff | Splinter Review
2.35 KB, patch
benjamin
: review+
Details | Diff | Splinter Review
84.84 KB, patch
benjamin
: review+
Details | Diff | Splinter Review
7.29 KB, text/plain
Details
8.71 KB, text/plain
Details
User-Agent:       Mozilla/5.0 (X11; U; OpenBSD macppc; en-US; rv:1.6) Gecko/20040302 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; OpenBSD macppc; en-US; rv:1.6) Gecko/20040302 Firefox/0.8

mozilla now works on all major platforms in openbsd
the patches are from our ports tree and I would like to get them back into mozilla

Reproducible: Always
Steps to Reproduce:
Attached patch moz-configure patch (obsolete) — Splinter Review
Attached patch ldap lber patchSplinter Review
Attached patch nspr configure patch (obsolete) — Splinter Review
Attached patch nspr openbsd.cfgSplinter Review
Attached patch xptcall makefile patch (obsolete) — Splinter Review
Attached patch complete alpha xptcinvoke file (obsolete) — Splinter Review
Attached patch complete alpha xptcstubs file (obsolete) — Splinter Review
Attached patch complete xptcinvoke amd64 file (obsolete) — Splinter Review
Attached patch complete xptcstubs amd64 file (obsolete) — Splinter Review
Attached patch complete xptcinvoke powerpc file (obsolete) — Splinter Review
Attached patch powerpc patch (obsolete) — Splinter Review
Attached patch complete xptcinvoke powerpc file (obsolete) — Splinter Review
Attached patch complete xptcstubs powerpc file (obsolete) — Splinter Review
Attached patch complete xptcinvoke sparc64 file (obsolete) — Splinter Review
Attached patch complete xptcstubs sparc64 file (obsolete) — Splinter Review
Comment on attachment 143039 [details] [diff] [review]
powerpc patch

oops, duplicate of 143038
Attachment #143039 - Attachment is obsolete: true
Status: UNCONFIRMED → NEW
Ever confirmed: true
Peter:
Is it possible to make one big all-in-one patch which includes the new files, too ?
What versions of OpenBSD have these patches been tested with?  Some of the
changes (like the pthread changes) look like they wouldn't work with older
versions of OpenBSD (we worked there once a long time ago).  I'd like to see a
minimally supported version in a doc somewhere.  People never tell us when
things work, only then they break so we have no idea who's using what.   Also,
can you put a more descriptive label on the patches?  Several of those listed as
'patch' are actually whole files.

Assignee: general → nobody
Component: Browser-General → Build Config
QA Contact: general → core.build-config
Attached file all patches/files in one tgz file (obsolete) —
Attachment #143034 - Attachment description: alpha patch → complete alpha xptcinvoke file
Attachment #143035 - Attachment description: alpha patch → complete alpha xptcstubs file
Attachment #143036 - Attachment description: amd64 patch → complete xptcinvoke amd64 file
Attachment #143037 - Attachment description: amd64 patch → complete xptcstubs amd64 file
Attachment #143038 - Attachment description: powerpc patch → complete xptcinvoke powerpc file
Attachment #143040 - Attachment description: powerpc patch → complete xptcinvoke powerpc file
Attachment #143041 - Attachment description: powerpc patch → complete xptcstubs asm powerpc file
Attachment #143042 - Attachment description: powerpc patch → complete xptcstubs powerpc file
Attachment #143043 - Attachment description: sparc64 patch → complete xptcinvoke asm sparc64 file
Attachment #143044 - Attachment description: sparc64 patch → complete xptcinvoke sparc64 file
Attachment #143045 - Attachment description: sparc64 patch → complete xptcstubs sparc64 file
-pthread appeared in openbsd 2.9 (more than three years ago)

In openbsd 3.4 - were we got moz to work for the first time (see #124958), moz
worked on alpha, i386, sparc and sparc64
Now on the upcomming 3.5, powerpc and amd64 are added
Comment on attachment 143027 [details] [diff] [review]
moz-configure patch

Is there a reason that the MKSHLIB_FORCE_ALL & MKSHLIB_UNFORCE_ALL vars are
being explicitly unset?    I think all of the MKSHLIB related lines can be
removed completely.  The defaults listed on line 733 of configure.in should
just work.
Attachment #143027 - Attachment description: patch → moz-configure patch
Attachment #143027 - Attachment is patch: true
Attachment #143028 - Attachment description: generic patch → ldap lber patch
Attachment #143028 - Flags: review?(dmose)
Comment on attachment 143029 [details] [diff] [review]
nspr configure patch

Is setting LDFLAGS necessary? $_PTHREAD_LDFLAGS is already added to $OS_LIBS.
Attachment #143029 - Attachment description: patch → nspr configure patch
Attachment #143030 - Attachment description: patch → nspr openbsd.cfg
Attachment #143030 - Flags: superreview?(wchang0222)
Attachment #143030 - Flags: review+
Attachment #143031 - Attachment description: patch → nspr openbsd.h patch
Attachment #143031 - Flags: superreview?(wchang0222)
Attachment #143031 - Flags: review+
Attachment #143032 - Attachment description: patch → NSS openbsd patch
Attachment #143032 - Flags: review?(wchang0222)
Attachment #143033 - Attachment description: patch → xptcall makefile patch
Attachment #143033 - Flags: review+
Comment on attachment 143028 [details] [diff] [review]
ldap lber patch

r+sr=dmose
Attachment #143028 - Flags: superreview+
Attachment #143028 - Flags: review?(dmose)
Attachment #143028 - Flags: review+
(In reply to comment #25)
> (From update of attachment 143027 [details] [diff] [review])
> Is there a reason that the MKSHLIB_FORCE_ALL & MKSHLIB_UNFORCE_ALL vars are
> being explicitly unset?    I think all of the MKSHLIB related lines can be
> removed completely.  The defaults listed on line 733 of configure.in should
> just work.

Yes, you are right, those four lines can go.
(In reply to comment #26)
> (From update of attachment 143029 [details] [diff] [review])
> Is setting LDFLAGS necessary? $_PTHREAD_LDFLAGS is already added to $OS_LIBS.

Copy/paste from the ../configure.in patch, this line can also go away.
Comment on attachment 143032 [details] [diff] [review]
NSS openbsd patch

r=wtc.

What's the difference between the outputs of 'uname -p'
and 'arch -s'?

Do we really need to pass -fPIC to the *linker* when we
build a shared library?
Attachment #143032 - Flags: review?(wchang0222) → review+
Comment on attachment 143030 [details] [diff] [review]
nspr openbsd.cfg

r=wtc.

Is the removal of __arm32__ support intentional?
Attachment #143030 - Flags: superreview?(wchang0222) → superreview+
Comment on attachment 143031 [details] [diff] [review]
nspr openbsd.h patch

r=wtc.

Is the removal of __arm32__ support intentional?

Do all the versions of OpenBSD that we care about
support the IPv6 socket API?
Attachment #143031 - Flags: superreview?(wchang0222) → superreview+
(In reply to comment #30)
> (From update of attachment 143032 [details] [diff] [review])
> r=wtc.
> 
> What's the difference between the outputs of 'uname -p'
> and 'arch -s'?

Completely different :-)

bagheera:~ $ uname -p ; arch -s
Intel Pentium III ("GenuineIntel" 686-class, 512KB L2 cache)
i386

> 
> Do we really need to pass -fPIC to the *linker* when we
> build a shared library?

Yes
[from espie@openbsd.org]
"You must reuse -fPIC. We've had platforms in the past where this makes a
difference:
- the compiler may have to compile extra stub code (constructors, destructors,
for instance)
- the compiler may select different library path (we've had fpic/libgcc.a)"

(In reply to comment #31)
> (From update of attachment 143030 [details] [diff] [review])
> r=wtc.
> 
> Is the removal of __arm32__ support intentional?
> 
Yes, support in openbsd was removed after 2.8 and that's really old.
> Do all the versions of OpenBSD that we care about
> support the IPv6 socket API?

yes
Attachment #143034 - Flags: review?(BradleyJunk)
Peter, can you please attach an updated patch for the configure.in changes?  Thanks.
Attachment #143027 - Attachment is obsolete: true
Attachment #143029 - Attachment is obsolete: true
Attachment #143367 - Flags: review+
Attachment #143368 - Flags: review+
Assigning bug to author.
Assignee: nobody → wilfried
Comment on attachment 143368 [details] [diff] [review]
nspr configure patch

Just a minor question: do we really need to define _THREAD_SAFE?
Is that done by the -pthread compiler flag?
(In reply to comment #40)
> Just a minor question: do we really need to define _THREAD_SAFE?
> Is that done by the -pthread compiler flag?

-pthread defines _POSIX_THREADS
If moz doesn't check on _THREAD_SAFE (as a quick glimpse seems to indicate) it
can also go.
All of the patches have been checked in (including respective client branches &
trunks) with the exception of the xptcall changes and the NSS patch.
*** Bug 124958 has been marked as a duplicate of this bug. ***
Attachment #143034 - Flags: review?(BradleyJunk) → review?(shaver)
I came here from the bonsai checkin list at 03/09/2004 23:46.

Is this bug related to Bug 163013 and Bug 232742 ?

In the attachment 140309 [details] [diff] [review], amd64 platform is defined as "__x86_64__".
And a part of this attachment is merged into the trunk at 03/08/2004 19:10.

On the other hand, in the rev. 5.3 of
mozilla/directory/c-sdk/ldap/libraries/liblber/lber-int.h, 
amd64 platform is defined as "__amd64__".
AMD64's architecture name is defined as x86-64 as comment #44 stated.
Please change this. It seems to be a race condition in check-ins ;-)
Blocks: 237202
Depends on: 232742
Attachment #144400 - Flags: review?(wchang0222)
Comment on attachment 144400 [details] [diff] [review]
nspr prprf.c va_copy patch (not needed for NSPR 4.6/Mozilla 1.8 or newer)

r=wtc.	This patch is suitable for NSPR 4.5/Mozilla 1.7
or older.  In newer NSPR releases, I fixed this porting
problem by completely eliminating the VARARGS_ASSIGN
macro, so this patch is not needed there.
Attachment #144400 - Attachment description: nspr prprf.c va_copy patch → nspr prprf.c va_copy patch (not needed for NSPR 4.6/Mozilla 1.8 or newer)
Attachment #144400 - Flags: review?(wchang0222) → review+
Comment on attachment 143034 [details] [diff] [review]
complete alpha xptcinvoke file

Other than that we probably don't want to put more code under Netscape's
copyright (and as of 1998, no less -- this bug's not _that_ old!), this looks
OK.

Please fix the copyright and date before committing.
Attachment #143034 - Flags: review?(shaver) → review+
Product: Browser → Seamonkey
What can I do to help get this bug moving again?

/be
Product: Mozilla Application Suite → Core
Benjamin, Luser: can one of you take this and help get the patches updated and landed?

/be
Flags: blocking1.9+
Version: Trunk → 1.8 Branch
Summary: openbsd configuration fixes for alpha, amd64, i386, macppc and sparc64 → openbsd configuration fixes for alpha, amd64, arm, i386, macppc and sparc64
Brendan, please CC r? the right people...
Attachment #143084 - Attachment is obsolete: true
Attachment #275702 - Flags: superreview?(brendan)
Attachment #275702 - Flags: review?(brendan)
Attachment #275702 - Flags: approval1.8.1.7?
Attachment #275702 - Flags: approval1.8.0.14?
Attached file Xptcall files (against 1.8 branch) (obsolete) —
Martynas Venckus provided a new patch against the 1.8 branch (trunk will follow). This ZIP file includes a patch for xpcom/reflect/xptcall/src/md/unix/Makefile.in and all the respective files for arm/sparc64/ppc/alpha/amd64.
Attachment #143033 - Attachment is obsolete: true
Attachment #143034 - Attachment is obsolete: true
Attachment #143035 - Attachment is obsolete: true
Attachment #143036 - Attachment is obsolete: true
Attachment #143037 - Attachment is obsolete: true
Attachment #143038 - Attachment is obsolete: true
Attachment #143040 - Attachment is obsolete: true
Attachment #143041 - Attachment is obsolete: true
Attachment #143042 - Attachment is obsolete: true
Attachment #143043 - Attachment is obsolete: true
Attachment #143044 - Attachment is obsolete: true
Attachment #143045 - Attachment is obsolete: true
Comment on attachment 275703 [details]
Xptcall files (against 1.8 branch)

lack of communication :)
Attachment #275703 - Attachment is obsolete: true
One big zip file is not the way to get review. It's much better to split the patch up by module (http://www.mozilla.org/owners.html is still the source -- there's a single-field form in which you can type a relative source pathname to find which module a file belongs to) and request r? of the right people.

Honestly, I'm sorry this bug did not get action, but I'm not your patch review requesting, unzipping and splitting and reattaching slave. The owners and peers who failed you last time should probably do that, this once, to make up for inaction. But it's a two way street, so if mcsmurf or martynas could do it, even better.

Cc'ing dveditz, who can help bless 1.8 branch landings for porting changes.

/be
Another approach: someone with commit access just unzip, verify that only ifdef'ed or otherwise build-configured-for-openbsd code is affected, ask dveditz to bless en-masse, and commit to the branch.

Trunk should probably be done the hard way.

/be
This is the Makefile change required for building, changes xpcom/reflect/xptcall/src/md/unix/Makefile.in. If this gets checked in, all the other new files need to be checked in, too.
Attachment #275813 - Flags: review?
Attachment #275813 - Flags: review? → review?(benjamin)
Comment on attachment 275813 [details] [diff] [review]
Makefile patch (1.8 branch)

Boy I hate the OS_TEST usage, but it seems to be standard in this makefile... I'm pretty sure we should end up using TARGET_CPU instead.
Attachment #275813 - Flags: review?(benjamin) → review+
This patch includes all the xptcall files needed for OpenBSD for the various platforms. I noticed the license header is missing in the amd64 files, those headers must of course be added before check-in (I didn't do it since I dunno who worked on this).
Martynas: Were you the only person working on the amd64 files?
Attachment #275702 - Attachment is obsolete: true
Attachment #275702 - Flags: superreview?(brendan)
Attachment #275702 - Flags: review?(brendan)
Attachment #275702 - Flags: approval1.8.1.7?
Attachment #275702 - Flags: approval1.8.0.14?
Dan Veditz: Would it be ok to check in the xptcall files patch on the 1.8 branch? Only OpenBSD is affected here. For the trunk a real review should be done I guess, but getting someone to review this patch for the 1.8 branch? Dunno if it is worth it, IMHO rather not.
Attachment #275976 - Flags: approval1.8.1.7?
(In reply to comment #59)
> Dan Veditz: Would it be ok to check in the xptcall files patch on the 1.8
> branch? Only OpenBSD is affected here. For the trunk a real review should be
> done I guess, but getting someone to review this patch for the 1.8 branch?
> Dunno if it is worth it, IMHO rather not.

I don't know if getting a review is worth it to you or not, but it's not getting approved for the (more conservative) branches without one. On the other hand these aren't supported platforms so we're not going to be too conservative about untested code as long as it's been approved (reviewed) by the module owner.
Attachment #275976 - Flags: review?(timeless)
Comment on attachment 275976 [details] [diff] [review]
Xptcall files patch (1.8 branch)

please get this reviewed by a module owner or peer before asking for branch approval
Attachment #275976 - Flags: approval1.8.1.7?
Attachment #275976 - Flags: review?(timeless)
Attachment #275976 - Flags: review+
Attachment #275976 - Flags: approval1.8.1.7?
Comment on attachment 275976 [details] [diff] [review]
Xptcall files patch (1.8 branch)

approved for 1.8.1.7, a=dveditz for release-drivers
Attachment #275976 - Flags: approval1.8.1.7? → approval1.8.1.7+
Comment on attachment 275982 [details]
xptcstubs_openbsd_amd64.cpp + license + small fixes

Please don't forget to commit this too, for amd64 support.
Attachment #275982 - Flags: review?(benjamin)
Attachment #275982 - Flags: approval1.8.1.7?
Comment on attachment 275980 [details]
xptcinvoke_openbsd_amd64.cpp + license

Please don't forget to commit this too, for amd64 support.
Attachment #275980 - Flags: review?(benjamin)
Attachment #275980 - Flags: approval1.8.1.7?
Comment on attachment 275980 [details]
xptcinvoke_openbsd_amd64.cpp + license

This should be part of the patch, and it's ok to land with the existing r+a
Attachment #275980 - Flags: review?(benjamin)
Attachment #275980 - Flags: approval1.8.1.8?
Attachment #275982 - Flags: review?(benjamin)
Attachment #275982 - Flags: approval1.8.1.8?
I'll check this in soon.
Keywords: checkin-needed
Checked in on the 1.8 branch.
Keywords: fixed1.8.1.8
Is this fixed?
Priority: -- → P5
Resolving as fixed. It is fixed on the 1.8.1 branch, but not on trunk because the patch needs updating for trunk.
Martynas: Please open a new bug for any trunk work.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: