Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#38465 closed defect (fixed)

ghc-bootstrap: universal variant doesn't install universal software

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: neverpanic (Clemens Lang)
Priority: Normal Milestone:
Component: ports Version: 2.1.3
Keywords: Cc: kitchen.andy@…
Port: ghc-bootstrap

Description

Enabling i386 support in ghc-bootstrap in r104166 had the effect of also turning on the default universal variant, but it doesn't work. Either fix the universal variant or disable it again.

$ sudo port install ghc-bootstrap +universal
Password:
--->  Computing dependencies for ghc-bootstrap
--->  Fetching distfiles for ghc-bootstrap
--->  Attempting to fetch ghc-7.0.4-x86_64-apple-darwin.tar.bz2 from http://haskell.org/ghc/dist/7.0.4/
--->  Verifying checksum(s) for ghc-bootstrap
--->  Extracting ghc-bootstrap
--->  Configuring ghc-bootstrap
--->  Building ghc-bootstrap
--->  Staging ghc-bootstrap into destroot
--->  Installing ghc-bootstrap @7.0.4_0+universal
--->  Activating ghc-bootstrap @7.0.4_0+universal
--->  Cleaning ghc-bootstrap
$ port -v installed ghc-bootstrap
The following ports are currently installed:
  ghc-bootstrap @7.0.4_0+universal (active) platform='darwin 12' archs='i386 x86_64'
$ port -q contents ghc-bootstrap | xargs -n 1 lipo -info 2>/dev/null | head -n 10
Non-fat file: /opt/local/share/ghc-bootstrap/bin/hp2ps is architecture: x86_64
Non-fat file: /opt/local/share/ghc-bootstrap/bin/hpc is architecture: x86_64
Non-fat file: /opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/Cabal-1.10.2.0/HSCabal-1.10.2.0.o is architecture: x86_64
input file /opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/Cabal-1.10.2.0/libHSCabal-1.10.2.0.a is not a fat file
Non-fat file: /opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/Cabal-1.10.2.0/libHSCabal-1.10.2.0.a is architecture: x86_64
input file /opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/Cabal-1.10.2.0/libHSCabal-1.10.2.0_p.a is not a fat file
Non-fat file: /opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/Cabal-1.10.2.0/libHSCabal-1.10.2.0_p.a is architecture: x86_64
Non-fat file: /opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/HSffi.o is architecture: x86_64
Non-fat file: /opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/array-0.3.0.2/HSarray-0.3.0.2.o is architecture: x86_64
input file /opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/array-0.3.0.2/libHSarray-0.3.0.2.a is not a fat file
$

Change History (10)

comment:1 Changed 11 years ago by neverpanic (Clemens Lang)

Cc: kitchen.andy@… added; cal@… removed
Owner: changed from kitchen.andy@… to cal@…
Status: newassigned

It should be disabled. I wasn't aware that having both i386 and x86_64 in the supported_archs automatically enables the universal variant.

comment:2 Changed 11 years ago by neverpanic (Clemens Lang)

Resolution: fixed
Status: assignedclosed

comment:3 Changed 11 years ago by cooljeanius (Eric Gallager)

If ghc-bootstrap can't be universal, all ports that depend on ghc should have their universal variants removed. So far I see these ports:

cpphs has the variants:
(+)universal: Build for multiple architectures
DoCon has the variants:
(+)universal: Build for multiple architectures
gtk2hs has the variants:
(+)universal: Build for multiple architectures
hs-Edison has the variants:
(+)universal: Build for multiple architectures
hs-EdisonAPI has the variants:
(+)universal: Build for multiple architectures
buddha has the variants:
(+)universal: Build for multiple architectures
darcs-devel has the variants:
(+)universal: Build for multiple architectures
distract has the variants:
(+)universal: Build for multiple architectures
Djinn has the variants:
(+)universal: Build for multiple architectures
ghc has the variants:
(+)universal: Build for multiple architectures
haskell-chunks has the variants:
(+)universal: Build for multiple architectures
haskell-hinstaller has the variants:
(+)universal: Build for multiple architectures
haskell-parsedate has the variants:
(+)universal: Build for multiple architectures
hat has the variants:
(+)universal: Build for multiple architectures
hmake has the variants:
(+)universal: Build for multiple architectures
hs-alex has the variants:
(+)universal: Build for multiple architectures
hs-chunks has the variants:
(+)universal: Build for multiple architectures
hs-happy has the variants:
(+)universal: Build for multiple architectures
hs-hinstaller has the variants:
(+)universal: Build for multiple architectures
hs-plugins has the variants:
(+)universal: Build for multiple architectures
hs-typenats has the variants:
(+)universal: Build for multiple architectures
hsshellscript has the variants:
(+)universal: Build for multiple architectures
lhs2tex has the variants:
(+)universal: Build for multiple architectures
missingh has the variants:
(+)universal: Build for multiple architectures
pxsl-tools has the variants:
(+)universal: Build for multiple architectures

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

It should be possible to enable the universal variant, shouldn't it? The oracle-instantclient port could be used as a model, though you may want to wait until I update it to version 11 as that should simplify some unnecessarily complicated aspects of the current port.

comment:5 Changed 11 years ago by neverpanic (Clemens Lang)

I'm not entirely sure the ghc-bootstrap port affects the architectures ghc can actually use. Think of a C compiler: A compiler compiled in i386 can still generate x86_64 code. Somebody would have to evaluate, if this is actually possible (and if it is, add depends_skip_archcheck ghc-bootstrap to the ghc port).

Technically it would also be possible to provide a universal ghc-bootstrap port using lipo and merging. I'm not going to put a lot of effort into that, though…

comment:6 in reply to:  1 Changed 11 years ago by jmroot (Joshua Root)

Replying to cal@…:

I wasn't aware that having both i386 and x86_64 in the supported_archs automatically enables the universal variant.

Actually it's more like having only one item in supported_archs automatically disables it. As do use_configure no and use_xmkmf yes.

comment:7 Changed 11 years ago by cooljeanius (Eric Gallager)

Someone might want to cc sean@… on this; he just updated a bunch of the haskell ports...

comment:8 in reply to:  7 ; Changed 11 years ago by seanfarley (Sean Farley)

Replying to egall@…:

Someone might want to cc sean@… on this; he just updated a bunch of the haskell ports...

I tried to make sure all the ports I updated followed the no-universal advice from this ticket. Let me know if I missed any.

comment:9 in reply to:  8 ; Changed 11 years ago by cooljeanius (Eric Gallager)

Replying to sean@…:

Replying to egall@…:

Someone might want to cc sean@… on this; he just updated a bunch of the haskell ports...

I tried to make sure all the ports I updated followed the no-universal advice from this ticket. Let me know if I missed any.

larryv reverted all the universal_variant no's in the Haskell ports in r104471... apparently the Haskell portgroup handles it as of r100403.

Edit: still, though, not all ports that depend on ghc actually use the Haskell portgroup.

Last edited 11 years ago by cooljeanius (Eric Gallager) (previous) (diff)

comment:10 in reply to:  9 Changed 11 years ago by seanfarley (Sean Farley)

Replying to egall@…:

Replying to sean@…:

Replying to egall@…:

Someone might want to cc sean@… on this; he just updated a bunch of the haskell ports...

I tried to make sure all the ports I updated followed the no-universal advice from this ticket. Let me know if I missed any.

larryv reverted all the universal_variant no's in the Haskell ports in r104471... apparently the Haskell portgroup handles it as of r100403.

Yes, it's already handled in the portgroup.

Note: See TracTickets for help on using tickets.