Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#27574 closed submission (fixed)

obc: Portfile and patch for Oxford Oberon 2 compiler

Reported by: jking+macports@… Owned by: ryandesign (Ryan Schmidt)
Priority: Normal Milestone:
Component: ports Version: 1.9.2
Keywords: oberon obc oberon2 Cc:
Port: obc

Description

Attached is a Portfile and single patch for the Oxford Oberon 2 compiler (obc).

Attachments (4)

Portfile (957 bytes) - added by jking+macports@… 10 years ago.
patch-destdir.diff (991 bytes) - added by jking+macports@… 10 years ago.
Updated version for 2.9.0 to correct DESTDIR
obc-2.8.4-to-2.9.0.diff (1.7 KB) - added by jking+macports@… 10 years ago.
obc-ryandesign.diff (1.5 KB) - added by ryandesign (Ryan Schmidt) 10 years ago.
possible patch

Download all attachments as: .zip

Change History (19)

comment:1 Changed 10 years ago by ryandesign (Ryan Schmidt)

Owner: changed from macports-tickets@… to ryandesign@…
Status: newassigned
Summary: Portfile and patch for Oxford Oberon 2 compilerobc: Portfile and patch for Oxford Oberon 2 compiler

Thanks.

comment:2 Changed 10 years ago by ryandesign (Ryan Schmidt)

Why version 2.8.3? 2.8.4 is out since February.

What is the reason for the line "configure.build_arch i386"? Are you trying to prevent building on PowerPC machines, or on 64-bit machines? Currently this prevents both. I assume you meant the latter, since I do see a segmentation fault when trying to build for x86_64 on Snow Leopard, which goes away when I use i386. Either way, the correct way is to use "supported_archs", not set configure.build_arch directly.

I'm surprised that /opt/local/lib/obc/obb1 and /opt/local/lib/obc/obc1 are still ending up built for x86_64, not i386. Is that how it's supposed to be?

I'll remove "--prefix=/opt/local" from the configure.args. Hardcoding /opt/local is not ok, and MacPorts already puts "--prefix=${prefix}" in configure.pre_args.

comment:3 Changed 10 years ago by jking+macports@…

My apologies. Their wiki still links to 2.8.3 as the latest version for generic Unix.

Indeed, the compiler only works on 32-bit Intel systems; a 64-bit compiler generates invalid code. Having obb and obc1 generated for x86_64 is an artifact of the build process and works okay.

Also, my apologies on the --prefix=/opt/local thing. That was left in during debugging when I was testing the DESTDIR patch.

I have attached a new Portfile and patchfile. Thanks.

Changed 10 years ago by jking+macports@…

Attachment: Portfile added

comment:4 in reply to:  3 Changed 10 years ago by ryandesign (Ryan Schmidt)

Replying to jking+macports@…:

Indeed, the compiler only works on 32-bit Intel systems; a 64-bit compiler generates invalid code.

And what about on PowerPC? I was able to compile the port on a Power Mac G4, but I don't know if the software works.

comment:5 Changed 10 years ago by jking+macports@…

Unfortunately, I don't have access to a PPC system to test it on, so I don't know either. Given the compilation notes at here I don't think it will work (quotes like "Set up to use the 10.5 toolkit and generate i386 code by cp macport/jhbuild-custom ~/.jhbuild-custom. (Some things don't work in 64 bits yet." and "Set the compiler for 32 bits with configure CC='gcc -arch i386'.").

comment:6 Changed 10 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: assignedclosed

Those note seem to be for the specific case of compiling a Leopard-compatible version of obc while running Snow Leopard. Certainly in that case you would need to specify 32-bit arch flags, because Snow Leopard builds 64-bit by default. I don't see any indication there that obc is expected not to work on PowerPC, so I won't make that assumption. I committed the port in r74141, adding the standard modeline, and changing supported_archs to "i386 ppc". If someone notices PowerPC problems I'm sure they'll file a ticket. Thanks for the port!

comment:7 Changed 10 years ago by mike@…

Much confusion has resulted from a failure to contact the original author of the software. This port is based on release 2.8, obsolete now that 2.9 is out with significant bugfixes. Please get in touch before releasing a new port! -- Mike Spivey

comment:8 Changed 10 years ago by jking+macports@…

Professor Spivey, thank you for your comments via out-of-band email; I've taken them to heart.

I've attached a new portfile that includes a check for architecture to selectively enable the JIT code. I've also updated the portfile to build the latest revision of the compiler. I've attached a patch to the portfile to this ticket, along with an updated patch-destdir.diff file.

Changed 10 years ago by jking+macports@…

Attachment: patch-destdir.diff added

Updated version for 2.9.0 to correct DESTDIR

comment:9 Changed 10 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: closedreopened

In the conditional, I think we should check ${configure.build_arch} instead of ${os.arch}. Also, I think there's a problem with the line "configure.args-delete --disable-jit" since "--disable-jit" isn't in the configure.args to begin with so there's nothing to delete. Did you mean "configure.args-append --disable-jit"?

In the future, we should do port updates in new tickets, not reusing existing resolved ones.

comment:10 Changed 10 years ago by jking+macports@…

Thank you Ryan; I've updated the Portfile to reflect your changes. My apologies; I'm not super-familiar with the Portfile format just yet.

Changed 10 years ago by jking+macports@…

Attachment: obc-2.8.4-to-2.9.0.diff added

Changed 10 years ago by ryandesign (Ryan Schmidt)

Attachment: obc-ryandesign.diff added

possible patch

comment:11 Changed 10 years ago by ryandesign (Ryan Schmidt)

I still don't think the conditional is what you want. The way you have it in your latest patch, you're saying that we should use --disable-jit on i386, otherwise don't. Isn't that exactly the opposite of what we want? According to the developer, the just-in-time compiler only works on i386, so we should use --disable-jit unless we're building for i386, in which case we want to remove --disable-jit so that JIT is used.

But I wonder if we ever need the --disable-jit argument at all. It built fine for me on both i386 and ppc if I didn't specify that option. I assume the software would enable JIT if possible, and leave it off if not. If that's so, then we can simply do this, can't we?

comment:12 Changed 10 years ago by jking+macports@…

Sheesh, I'm sorry. My only excuse is that it's finals week. In my communication with Professor Spivey, he recommended that the JIT be explicitly disabled on non-i386 platforms. However, if you are able to correctly build the code on PPC then I think using your patch file is fine. Sorry again for the confusion.

comment:13 in reply to:  12 ; Changed 10 years ago by mike@…

The configure script attempts to recognise the host architecture, and enables the JIT if the architecture is one of the ones supported, from this short list: [x86]. So it shouldn't be necessary to specify --disable-jit, whatever the architecture.

If building on an x86-64 machine, the C components (i.e. the runtime system) need to be built in 32-bit. It doesn't matter whether the OCaml components (i.e. the Oberon compiler) are built with the 32-bit or the 64-bit OCaml compiler. I don't know much about MacPorts, so I don't know how accurately you can specify that requirement.

comment:14 in reply to:  13 ; Changed 10 years ago by ryandesign (Ryan Schmidt)

Resolution: fixed
Status: reopenedclosed

Replying to mike@…:

The configure script attempts to recognise the host architecture, and enables the JIT if the architecture is one of the ones supported, from this short list: [x86].

When you say x86, you mean i386? The possible architectures in MacPorts are i386, x86_64, ppc, and ppc64.

So it shouldn't be necessary to specify --disable-jit, whatever the architecture.

Ok, I commited my patch in r74441.

If building on an x86-64 machine, the C components (i.e. the runtime system) need to be built in 32-bit. It doesn't matter whether the OCaml components (i.e. the Oberon compiler) are built with the 32-bit or the 64-bit OCaml compiler. I don't know much about MacPorts, so I don't know how accurately you can specify that requirement.

I believe we already specify that. We say "supported_archs i386 ppc" meaning that MacPorts will pass "-arch i386" (or "-arch ppc") in the CFLAGS, CXXFLAGS and LDFLAGS when building obc. MacPorts will enforce this architecture for all dependencies as well, except that we also write "depends_skip_archcheck ocaml" so that MacPorts does not attempt to enforce any particular architecture of ocaml.

comment:15 in reply to:  14 Changed 10 years ago by mike@…

Replying to ryandesign@…:

When you say x86, you mean i386? The possible architectures in MacPorts are i386, x86_64, ppc, and ppc64.

Yes, i386: although in practice that really means that the code suits processors that >= i486, and wouldn't work on the original 80386/80387. Since there aren't any macs that are < Pentium, it's a moot point that appeals only to avid readers of the Intel architecture manuals.

If building on an x86-64 machine, the C components (i.e. the runtime system) need to be built in 32-bit. It doesn't matter whether the OCaml components (i.e. the Oberon compiler) are built with the 32-bit or the 64-bit OCaml compiler. I don't know much about MacPorts, so I don't know how accurately you can specify that requirement.

I believe we already specify that. We say "supported_archs i386 ppc" meaning that MacPorts will pass "-arch i386" (or "-arch ppc") in the CFLAGS, CXXFLAGS and LDFLAGS when building obc. MacPorts will enforce this architecture for all dependencies as well, except that we also write "depends_skip_archcheck ocaml" so that MacPorts does not attempt to enforce any particular architecture of ocaml.

Sounds good to me.

Note: See TracTickets for help on using tickets.