ghc: update to latest version

[jwiegley@…]

ghc is up to 6.12.3, which builds and runs fine on Snow Leopard. However, even the ghc-devel is stuck at 6.11. Are these ports in need of a new maintainer?

[pieter.debaets@…]

Cc Me!

[akborder@…]

Cc Me!

[gonhidi@…]

Cc Me!

[dented42@…]

What exactly does fixing this require? I mean, what work is involved? If I knew what to do, I would be more then happy to cobble a patch together.

[dented42@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #26481.

[katelman@…]

Cc Me!

[gwright@…]

My patch for the underlying linker bugs on 64 bit Snow Leopard were accepted upstream last week. The changes introduced to support position independent code broke the Mach-O linker. The original author of the linker having left the project, a lot of reverse engineering was necessary.

The problematic relocations were specific to 64 bit platforms. The ghc binary installer from the main ghc web page was actually built on Leopard. It would run fine, but it wasn't possible to build a usable 64 bit ghc for 6.12.x or the upcoming 7.0.1 until last week.

I hope to update ghc within the next week or two. Depends on how many build patches are needed -- the build system is much improved from 6.10, but there will certainly be changes required for MacPorts.

[katelman@…]

Replying to gwright@…:

My patch for the underlying linker bugs on 64 bit Snow Leopard were accepted upstream last week. The changes introduced to support position independent code broke the Mach-O linker. The original author of the linker having left the project, a lot of reverse engineering was necessary.

The problematic relocations were specific to 64 bit platforms. The ghc binary installer from the main ghc web page was actually built on Leopard. It would run fine, but it wasn't possible to build a usable 64 bit ghc for 6.12.x or the upcoming 7.0.1 until last week.

I hope to update ghc within the next week or two. Depends on how many build patches are needed -- the build system is much improved from 6.10, but there will certainly be changes required for MacPorts.

Very interesting, thanks for the update. Clearly, it has required a lot of work. I thought something like what you wrote might be the case, but had trouble finding mention of it online anywhere.

[nerdling (Jeremy Lavergne)]

If you need any testers for changes to ghc let me know.

[me@…]

Cc Me!

[karoly@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

7.0.1 is out since November 2010. Is there any progress on updating the port to that version?

[benedikt.huber@…]

Cc Me!

[jdswinbank (John Swinbank)]

Cc Me!

[pusteblumekuchen@…]

7.2.2 is out since November 2011. Is there any progress on updating the port to that version?

[ryandesign (Ryan Carsten Schmidt)]

7.4.1 is out since February 2012. Greg, will you be updating this port?

[kitchen.andy@…]

Cc Me!

[kitchen.andy@…]

Hi All,

I've been working on updating the portfiles for GHC 7.4.2, I've decided to do it a slightly different way than the last guy. I'm going to create a port the installs the binary distribution of GHC, then I'll create a port that depends on that which will compile using the binary-distro as the bootstrap compiler. This will (hopefully) be less brittle and make the process relatively easy to maintain. The current GHC Port file is a bit of a mess (although a lot of this is because of patching that is no longer required)

I've attached my ghc-bootstrap portfile, I'll keep working on the GHC portfile that depends on it. the ghc-bootstrap file is quite straight forward, except for post-destroot code that fixes some install_name problems.

Any comments/thoughts/help is appreciated.

Kind regards

AK

[neverpanic (Clemens Lang)]

I think this approach is more feasible than the current one. However, you might want to run sudo port -v -y rev-upgrade after installing this port to discover more problems with linking. Remember rev-upgrade is by default automatically run after each installation since 2.1.0 and problems in your ghc-bootstrap port will cause rev-upgrade to mark consider it broken and attempt to re-install (which won't change anything, because you're installing from binaries).

I'm seeing:

Could not open /usr/local/lib/ghc-7.4.2/ghc-prim-0.2.0.0/libHSghc-prim-0.2.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/integer-gmp-0.4.0.0/libHSinteger-gmp-0.4.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/base-4.5.1.0/libHSbase-4.5.1.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/array-0.4.0.0/libHSarray-0.4.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/deepseq-1.3.0.0/libHSdeepseq-1.3.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/containers-0.4.2.1/libHScontainers-0.4.2.1-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/filepath-1.3.0.0/libHSfilepath-1.3.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/old-locale-1.0.0.4/libHSold-locale-1.0.0.4-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/old-time-1.1.0.0/libHSold-time-1.1.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/bytestring-0.9.2.1/libHSbytestring-0.9.2.1-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/unix-2.5.1.1/libHSunix-2.5.1.1-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/directory-1.1.0.2/libHSdirectory-1.1.0.2-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/pretty-1.1.1.0/libHSpretty-1.1.1.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/process-1.1.0.1/libHSprocess-1.1.0.1-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/Cabal-1.14.0/libHSCabal-1.14.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/bin-package-db-0.0.0.0/libHSbin-package-db-0.0.0.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/binary-0.5.1.0/libHSbinary-0.5.1.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/bin-package-db-0.0.0.0/libHSbin-package-db-0.0.0.0-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/bin-package-db-0.0.0.0/libHSbin-package-db-0.0.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/ghc-7.4.2/libHSghc-7.4.2-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/hoopl-3.8.7.3/libHShoopl-3.8.7.3-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/ghc-7.4.2/libHSghc-7.4.2-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/hpc-0.5.1.1/libHShpc-0.5.1.1-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/ghc-7.4.2/libHSghc-7.4.2-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/template-haskell-2.7.0.0/libHStemplate-haskell-2.7.0.0-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/ghc-7.4.2/libHSghc-7.4.2-ghc7.4.2.dylib)
Could not open /usr/local/lib/ghc-7.4.2/time-1.4/libHStime-1.4-ghc7.4.2.dylib: Error opening or reading file (referenced from /opt/local/lib/ghc-7.4.2/haskell98-2.0.0.1/libHShaskell98-2.0.0.1-ghc7.4.2.dylib)

Note that these are probably not the only locations where the missing files in /usr/local are referenced; rev-upgrade only prints the first occurrence for each.

[kitchen.andy@…]

Thanks Cal,

Damn, I didn't catch this because I already had ghc-7.4.2 installed in /usr/local as well, I should rename this temporarily while I'm hacking macports.

I'm in the process of making my install name fixing code more general, I could set it up to fix /usr/local references as well.

Although most of this might be moot, I've had to drop the ghc-boostrap version down to 7.0.4, because 7.4.2 ironically doesn't compile itself.

Also, What's the best way to encode this fact in a portfile?

Thanks in advance,

AK

[kitchen.andy@…]

Updated ghc-bootstrap portfile

[kitchen.andy@…]

With 7.0.4 I get a weird warning from rev-upgrade.

Warning: Error parsing file /opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/HSffi.o: Premature end of data, possibly corrupt file

Does anyone have pointers on how to debug this?

Kind Regards

AK

[neverpanic (Clemens Lang)]

Replying to kitchen.andy@…:

Also, What's the best way to encode this fact in a portfile?

Probably just add a comment in proximity to the version.

Replying to kitchen.andy@…:

Warning: Error parsing file /opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/HSffi.o: Premature end of data, possibly corrupt file

You can safely ignore this for now. For some reason file(1) recognizes some files as Mach-O binaries that in fact are not. I have yet to debug and fix this, but it's (or should be) non-critical.

[kitchen.andy@…]

Ok so, Just spent two hours debugging a GHC build error, FYI everyone using clang as the preprocessor breaks stuff. Notably building ghc itself.

I'm still going to leave the ghc-bootstrap version as 7.0.4 because that's the current haskell platform version and it seems free of the freaky linking problems and ghc does a 2-stage bootstrap anyway.

Regards

AK

[kitchen.andy@…]

Ok, so here are the portfiles for GHC 7.4.2!

The Port even fixes GHC build system link errors.

Please test!

[kitchen.andy@…]

GHC bootstrap portfile

[kitchen.andy@…]

GHC 7.4.2 portfile

[kitchen.andy@…]

FYI here is the ticket for the GHC linking errors.

​http://hackage.haskell.org/trac/ghc/ticket/7028

[neverpanic (Clemens Lang)]

The good part: I think the important stuff built successfully. The bad part: The build fails when building the users guide (which I guess only happens if you have dblatex, xsltproc and latex installed). I'm attaching the log for you to take a look. Maybe there's an option to disable building the users guide?

[neverpanic (Clemens Lang)]

Cc Me!

[nerdling (Jeremy Lavergne)]

With respect to Portfile.3​:

Warning: Error parsing file /opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/HSffi.o: Premature end of data, possibly corrupt file

Should a .o file make it past destroot?

[kitchen.andy@…]

Replying to cal@…:

The good part: I think the important stuff built successfully. The bad part: The build fails when building the users guide (which I guess only happens if you have dblatex, xsltproc and latex installed). I'm attaching the log for you to take a look. Maybe there's an option to disable building the users guide?

Thanks cal, I'll try and have a look at that later in the week, one would expect there to be an option to disable the building of the users guide.

Ideally, I would like to write a test phase as well.

[kitchen.andy@…]

Replying to snc@…:

With respect to Portfile.3​:

Warning: Error parsing file /opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/HSffi.o: Premature end of data, possibly corrupt file

Should a .o file make it past destroot?

Short answer, yes.

Long answer, in ghc 7.4.2 this .o file is replaced with a .dylib. I believe having this .o file around is actually a way for ghc to perform non-standard static-linking. That being said, I'm really not quite sure why it's there, but I am quite sure it is necessary.

If the warning really annoys you, you can deactivate (or uninstall) ghc-bootstrap when you are not actively building ghc.

[karoly@…]

Cc Me!

[kitchen.andy@…]

Thanks cal, I'll try and have a look at that later in the week, one would expect there to be an option to disable the building of the users guide.

Well the best I can come up with is this: pre-build {

system "echo >${worksrcpath}/docs/users_guide/ghc.mk"

}

Maybe I'm just not very clever, or the GHC build system is not particularly flexible.

[neverpanic (Clemens Lang)]

I'm attaching the Portfile with some modifications (you don't have to define some of the variables in phases explicitly).

I think the value of having a current ghc outweighs the dblatex problem, so I'm probably going to commit this soon. The easiest way to disable building PDF/PS documentation would probably be to patch configure.ac to always set BUILD_DOCBOOK_PS=NO and BUILD_DOCBOOK_PDF=NO (lines 778 and following), but maybe instead of disabling building the documentation we should fix the problem with building it.

Do you want to be listed as maintainer for this port? If yes, please state which email address you want me to put into the Portfile. Also please decide whether you want openmaintainer to be added (as described in ​http://guide.macports.org/#project.update-policies).

I'm not sure what to do with the ghc-devel port. I guess leaving it around with the older version isn't the way to go, so I'd probably make it a stub port and mark it replaced_by ghc.

[neverpanic (Clemens Lang)]

My version of the Portfile seems to miscompile ghc. I don't yet know why, I'll try to have a look tomorrow.

[kitchen.andy@…]

Replying to cal@…:

My version of the Portfile seems to miscompile ghc. I don't yet know why, I'll try to have a look tomorrow.

Damn, what variant? My extensive testing (that is compiling a hello world program) has show that the gcc47 variant works.

Did you run the test suite? Perhaps we could automate the checking of various gcc variants. The current included list is just taken from the Portfile guide.

[kitchen.andy@…]

Replying to cal@…:

I'm attaching the Portfile with some modifications (you don't have to define some of the variables in phases explicitly).

Thanks!

I think the value of having a current ghc outweighs the dblatex problem, so I'm probably going to commit this soon. The easiest way to disable building PDF/PS documentation would probably be to patch configure.ac to always set BUILD_DOCBOOK_PS=NO and BUILD_DOCBOOK_PDF=NO (lines 778 and following), but maybe instead of disabling building the documentation we should fix the problem with building it.

Sure, I like the idea of fixing it, although this is entirely outside of my expertise, I literally know nothing about any of those tools, perhaps I could ask on the haskell mailing list/IRC channel. I'll try and do this (at least the patch) over the weekend...

In your opinion is using that patch as opposed to wiping doc/user_guide/ghc.mk worth the dependency on autoconf? Or is that dep implicit?

Do you want to be listed as maintainer for this port? If yes, please state which email address you want me to put into the Portfile. Also please decide whether you want openmaintainer to be added (as described in ​http://guide.macports.org/#project.update-policies).

Sure, that sounds great, kitchen.andy+macports@… would be my email address. adding openmaintainer would be best.

I'm not sure what to do with the ghc-devel port. I guess leaving it around with the older version isn't the way to go, so I'd probably make it a stub port and mark it replaced_by ghc.

In the next few weeks I'd like to do a ghc-devel port for 7.5, mainly in preparation for 7.6 which has a lot of features that I am excited about (deferred type errors and holes). The current nightly seemed to compile from source with no babysitting, so touch wood, it should be straight forward.

[kitchen.andy@…]

Replying to cal@…:

My version of the Portfile seems to miscompile ghc. I don't yet know why, I'll try to have a look tomorrow.

I've setup the Portfile with a test phase, to help debug the mis-compilations. For me on gcc47 I get 6 unexpected failures 4 look harmless, 2 look iffy but are in the objective-c bridge, which doesn't seem very popular. I'll try and ask about 7.4.2 and the objective-c bridge on the IRC channel. It's possible that these features have only really be tested with apple-gcc42. Perhaps, I should add a variant for that.

[neverpanic (Clemens Lang)]

patch to disable building documentation with dblatex

[neverpanic (Clemens Lang)]

I've attached a patch that will disable building PDF documentation with dblatex even if it's installed. Since the patch changes configure and not configure.in we don't need to add a dependency on autotools.

However, a build-dependency on libxslt is needed, because it is being used to generate HTML documentation.

I've added the patch and dependency and fixed some minor issues (trailing whitespace, unneeded use of tags in distfiles) and attached another version of the Portfile.

My wording on "miscompiles ghc" could probably have been better. I didn't want to say "ghc compiles but doesn't work correctly", but "ghc doesn't compile at all". I haven't found out why this is happening, and even more strange, it seems to work for you. I'll attach my main.log, maybe you have an idea why it fails?

[kitchen.andy@…]

Replying to cal@…:

I've attached a patch that will disable building PDF documentation with dblatex even if it's installed. Since the patch changes configure and not configure.in we don't need to add a dependency on autotools.

Awesome, thanks heaps.

However, a build-dependency on libxslt is needed, because it is being used to generate HTML documentation.

Thanks heaps for that too.

I've added the patch and dependency and fixed some minor issues (trailing whitespace, unneeded use of tags in distfiles) and attached another version of the Portfile.

Thanks again.

My wording on "miscompiles ghc" could probably have been better. I didn't want to say "ghc compiles but doesn't work correctly", but "ghc doesn't compile at all". I haven't found out why this is happening, and even more strange, it seems to work for you. I'll attach my main.log, maybe you have an idea why it fails?

Well, not sure exactly, but I've noticed compilation failures on occasion, that's why I disabled parallel builds. For me these errors were totally spurious and annoyingly seem to go away just by running make again. So try running 'port -kv install ghc' multiple times, does it stop at the same point or get further each time?

These seemingly non-deterministic failures could likely come from unspecified dependencies in the make file. If these dependencies are produced as a by-product of other rules, the success or failure of the make file could depend on the order the products were build, but still mostly work. I am as yet unable to reproduce these build errors.

Also this looks like a plumbing problem in the build system (it looks like it's generating a dep file to be included in some other makefile) as opposed to the problem being somewhere inside haskell code. I'm on lion, so my system make is reasonably new: GNU Make 3.81 This is probably one of the large system dependent variables, perhaps compiling with the macports gmake 3.82 could do the trick?

Hope that helps.

Kind Regards

AK

[kitchen.andy@…]

Small bugfix in portfile

[katelman@…]

Cc Me!

[neverpanic (Clemens Lang)]

I can't compile ghc anymore, though I'm not sure why this doesn't work now but worked fine before. I think I might have recently upgraded my Xcode and Command Line Tools to 4.3.3.

--->  Configuring ghc
checking for gfind... /opt/local/bin/gfind
checking for sort... /usr/bin/sort
checking version of ghc... 7.0.4
checking build system type... i386-apple-darwin11.4.0
checking host system type... i386-apple-darwin11.4.0
checking target system type... i386-apple-darwin11.4.0
Build platform inferred as: x86_64-apple-darwin
Host platform inferred as: x86_64-apple-darwin
Target platform inferred as: x86_64-apple-darwin
GHC build  : x86_64-apple-darwin
GHC host   : x86_64-apple-darwin
GHC target : x86_64-apple-darwin
configure: Building in-tree ghc-pwd
ld: warning: could not create compact unwind for _ffi_call_unix64: does not use RBP or RSP based frame
Undefined symbols for architecture x86_64:
  "_locale_charset", referenced from:
      _localeEncoding in libHSbase-4.3.1.0.a(PrelIOUtils.o)
  "_iconv_close", referenced from:
      _hs_iconv_close in libHSbase-4.3.1.0.a(iconv.o)
     (maybe you meant: _hs_iconv_close)
  "_iconv", referenced from:
      _hs_iconv in libHSbase-4.3.1.0.a(iconv.o)
     (maybe you meant: _hs_iconv, _hs_iconv_open , _hs_iconv_close )
  "_iconv_open", referenced from:
      _hs_iconv_open in libHSbase-4.3.1.0.a(iconv.o)
     (maybe you meant: _hs_iconv_open)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
configure: error: Building ghc-pwd failed
Command failed:  cd "/opt/local/var/macports/build/_opt_dports_lang_ghc/ghc/work/ghc-7.4.2" && ./configure --prefix=/opt/local --with-ghc=/opt/local/share/ghc-bootstrap/bin/ghc --with-gcc=/usr/bin/clang --with-iconv-includes=/opt/local/include --with-iconv-libraries=/opt/local/lib --with-gmp-includes=/opt/local/include --with-gmp-libraries=/opt/local/lib 
Exit code: 1

Possible related: ​http://hackage.haskell.org/trac/ghc/ticket/5019, ​http://hackage.haskell.org/trac/ghc/ticket/5293

Any suggestions?

[kitchen.andy@…]

Hi Cal,

I know exactly what causes this issue, libiconv had an ABI incompatible change at some point, where iconv_open was renamed _libiconv_open.

iceman:~ andy$ nm -Ug /usr/lib/libiconv.dylib | grep open
0000000000013171 T _iconv_open
iceman:~ andy$ nm -Ug /opt/local/lib/libiconv.dylib | grep open
0000000000016230 T _libiconv_open

This error is caused by the fact that in the binary distribution, the ghc runtime libraries are built against the old system libiconv, but for some reason the gcc that ghc is using to do its linking is picking up a newer version of libiconv somewhere on the search path.

I've tried putting /usr/lib on the front of LIBRARY_PATH, but maybe this isn't strong enough.

Perhaps something even stronger like LD_FLAGS='-Z -L/usr/lib' could do the trick?

I've attached an iconv.c file, what's the gcc -v output and success status of running: gcc iconv.c

[neverpanic (Clemens Lang)]

:) clemens@cSchlepptop:/opt/dports/lang/ghc$ /usr/bin/gcc -v iconv.c 
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.9~22/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00)
 /usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/cc1 -quiet -v -imultilib x86_64 -iprefix /usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/ -D__DYNAMIC__ iconv.c -fPIC -quiet -dumpbase iconv.c -mmacosx-version-min=10.7.4 -m64 -mtune=core2 -auxbase iconv -version -o /var/folders/hz/krd1dcl90hb7nc7pnysfvm640000gn/T//cch8SQhj.s
ignoring nonexistent directory "/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../../../i686-apple-darwin11/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/../../../../i686-apple-darwin11/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/include
 /usr/local/include
 /Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
GNU C version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00) (i686-apple-darwin11)
	compiled by GNU C version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.9.00).
GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=131072
Compiler executable checksum: ee05ffc2102727aa16c85f6ae97aa56c
 /usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/as -arch x86_64 -force_cpusubtype_ALL -o /var/folders/hz/krd1dcl90hb7nc7pnysfvm640000gn/T//ccprgfGB.o /var/folders/hz/krd1dcl90hb7nc7pnysfvm640000gn/T//cch8SQhj.s
 /usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/collect2 -dynamic -arch x86_64 -macosx_version_min 10.7.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.10.6.o -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/usr/lib/gcc/i686-apple-darwin11/4.2.1/x86_64 -L/usr/lib/i686-apple-darwin11/4.2.1 -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/llvm-gcc-4.2/bin/../lib/gcc -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/lib/gcc/i686-apple-darwin11/4.2.1 -L/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../.. -L/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/../../.. /var/folders/hz/krd1dcl90hb7nc7pnysfvm640000gn/T//ccprgfGB.o -lSystem -lgcc -lSystem
Undefined symbols for architecture x86_64:
  "_iconv_open", referenced from:
      _main in ccprgfGB.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
:( clemens@cSchlepptop:/opt/dports/lang/ghc$ gcc -v iconv.c 
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.6.3/lto-wrapper
Target: x86_64-apple-darwin11
Configured with: ../gcc-4.6.3/configure --prefix=/opt/local --build=x86_64-apple-darwin11 --enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/opt/local/lib/gcc46 --includedir=/opt/local/include/gcc46 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.6 --with-local-prefix=/opt/local --with-libiconv-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.6 --with-gxx-include-dir=/opt/local/include/gcc46/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --enable-stage1-checking --disable-multilib --enable-lto --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --disable-ppl-version-check --with-pkgversion='MacPorts gcc46 4.6.3_3'
Thread model: posix
gcc version 4.6.3 (MacPorts gcc46 4.6.3_3) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.4' '-v' '-mtune=core2'
 /opt/local/libexec/gcc/x86_64-apple-darwin11/4.6.3/cc1 -quiet -v -D__DYNAMIC__ iconv.c -fPIC -quiet -dumpbase iconv.c -mmacosx-version-min=10.7.4 -mtune=core2 -auxbase iconv -version -o /var/folders/hz/krd1dcl90hb7nc7pnysfvm640000gn/T//ccQ9KOmh.s
GNU C (MacPorts gcc46 4.6.3_3) version 4.6.3 (x86_64-apple-darwin11)
	compiled by GNU C version 4.6.3, GMP version 5.0.4, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3/../../../../../x86_64-apple-darwin11/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3/include
 /opt/local/include
 /opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
GNU C (MacPorts gcc46 4.6.3_3) version 4.6.3 (x86_64-apple-darwin11)
	compiled by GNU C version 4.6.3, GMP version 5.0.4, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7b044bf09794dd484b19dfba21993f39
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.4' '-v' '-mtune=core2'
 /opt/local/bin/as -v -arch x86_64 -force_cpusubtype_ALL -o /var/folders/hz/krd1dcl90hb7nc7pnysfvm640000gn/T//ccbj0i0g.o /var/folders/hz/krd1dcl90hb7nc7pnysfvm640000gn/T//ccQ9KOmh.s
Apple Inc version cctools-822, GNU assembler version 1.38
COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.6.3/:/opt/local/libexec/gcc/x86_64-apple-darwin11/4.6.3/:/opt/local/libexec/gcc/x86_64-apple-darwin11/:/opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3/:/opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/
LIBRARY_PATH=/opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3/:/opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.4' '-v' '-mtune=core2'
 /opt/local/libexec/gcc/x86_64-apple-darwin11/4.6.3/collect2 -dynamic -arch x86_64 -macosx_version_min 10.7.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.10.5.o -L/opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3 -L/opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3/../../.. /var/folders/hz/krd1dcl90hb7nc7pnysfvm640000gn/T//ccbj0i0g.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v
collect2 version 4.6.3 (x86_64 Darwin)
/opt/local/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.7.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.10.5.o -L/opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3 -L/opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3/../../.. /var/folders/hz/krd1dcl90hb7nc7pnysfvm640000gn/T//ccbj0i0g.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v
@(#)PROGRAM:ld  PROJECT:ld64-128.2
Library search paths:
	/opt/local/lib/gcc46/gcc/x86_64-apple-darwin11/4.6.3
	/opt/local/lib/gcc46
	/usr/lib
	/usr/local/lib
Framework search paths:
	/Library/Frameworks/
	/System/Library/Frameworks/
Undefined symbols for architecture x86_64:
  "_libiconv_open", referenced from:
      _main in ccbj0i0g.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status

So it seems when using gcc, which is /opt/local/bin/gcc and pointing to /opt/local/bin/gcc-mp-4.6 on my system /opt/local/include is automatically in the include path, turning any iconv_open to libiconv_open.

Removing or re-creating the /opt/local/bin/gcc has no effect on the problem with the ghc port, though.

[neverpanic (Clemens Lang)]

Drilling further down, the command that gets executed and fails is

/usr/bin/llvm-gcc-4.2 -v -o utils/ghc-pwd/dist-boot/ghc-pwd -m64 -fno-stack-protector utils/ghc-pwd/dist-boot/Main.o -L/opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/directory-1.1.0.0 -L/opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/unix-2.4.2.0 -L/opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/old-time-1.0.0.6 -L/opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/old-locale-1.0.0.2 -L/opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/filepath-1.2.0.0 -L/opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/base-4.3.1.0 -L/opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/integer-gmp-0.2.0.3 -L/opt/local/share/ghc-bootstrap/lib/ghc-7.0.4/ghc-prim-0.2.0.0 -L/opt/local/share/ghc-bootstrap/lib/ghc-7.0.4 -lHSrtsmain -lHSdirectory-1.1.0.0 -lHSunix-2.4.2.0 -ldl -lHSold-time-1.0.0.6 -lHSold-locale-1.0.0.2 -lHSfilepath-1.2.0.0 -lHSbase-4.3.1.0 -liconv -lHSinteger-gmp-0.2.0.3 -lHSghc-prim-0.2.0.0 -lHSrts -lm -ldl -u _ghczmprim_GHCziTypes_Izh_static_info -u _ghczmprim_GHCziTypes_Czh_static_info -u _ghczmprim_GHCziTypes_Fzh_static_info -u _ghczmprim_GHCziTypes_Dzh_static_info -u _base_GHCziPtr_Ptr_static_info -u _base_GHCziWord_Wzh_static_info -u _base_GHCziInt_I8zh_static_info -u _base_GHCziInt_I16zh_static_info -u _base_GHCziInt_I32zh_static_info -u _base_GHCziInt_I64zh_static_info -u _base_GHCziWord_W8zh_static_info -u _base_GHCziWord_W16zh_static_info -u _base_GHCziWord_W32zh_static_info -u _base_GHCziWord_W64zh_static_info -u _base_GHCziStable_StablePtr_static_info -u _ghczmprim_GHCziTypes_Izh_con_info -u _ghczmprim_GHCziTypes_Czh_con_info -u _ghczmprim_GHCziTypes_Fzh_con_info -u _ghczmprim_GHCziTypes_Dzh_con_info -u _base_GHCziPtr_Ptr_con_info -u _base_GHCziPtr_FunPtr_con_info -u _base_GHCziStable_StablePtr_con_info -u _ghczmprim_GHCziBool_False_closure -u _ghczmprim_GHCziBool_True_closure -u _base_GHCziPack_unpackCString_closure -u _base_GHCziIOziException_stackOverflow_closure -u _base_GHCziIOziException_heapOverflow_closure -u _base_ControlziExceptionziBase_nonTermination_closure -u _base_GHCziIOziException_blockedIndefinitelyOnMVar_closure -u _base_GHCziIOziException_blockedIndefinitelyOnSTM_closure -u _base_ControlziExceptionziBase_nestedAtomically_closure -u _base_GHCziWeak_runFinalizzerBatch_closure -u _base_GHCziTopHandler_runIO_closure -u _base_GHCziTopHandler_runNonIO_closure -u _base_GHCziConcziIO_ensureIOManagerIsRunning_closure -u _base_GHCziConcziSync_runSparks_closure -u _base_GHCziConcziSignal_runHandlers_closure -Wl,-search_paths_first -lHSffi

I ran this from within ghc's ${worksrcpath} with and without LIBRARY_PATH set to /usr/lib:/opt/local/lib. Apparently the order of paths in this variable doesn't matter, the linking always fails. Shouldn't that be working correctly? Is this a bug in the linker or am I doing something wrong here?

[kitchen.andy@…]

Hey Buddy, it seems to maintain compatibility newer iconv.h hash defines iconv_open to libiconv_open.

--- from /opt/local/include/iconv.h line 70
#ifndef LIBICONV_PLUG
#define iconv_open libiconv_open
#endif

So this error is caused by using the _new_ header but linking with the _old_ library, so LIBRARY_PATH was a red herring.

What we really need to do is get the gcc that ghc is using to search /usr/include before /opt/local/include

Try using the C_INCLUDE_PATH

export C_INCLUDE_PATH="/usr/include"

also -isystem

CCFLAGS="-isystem/usr/include"

Both should have the effect of making /usr/include searched first:

iceman:misc andy$ C_INCLUDE_PATH=/usr/include gcc -v -liconv iconv.c
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.1/lto-wrapper
Target: x86_64-apple-darwin11
Configured with: ../gcc-4.7.1/configure --prefix=/opt/local --build=x86_64-apple-darwin11 --enable-languages=c,c++,objc,obj-c++,lto,fortran,java --libdir=/opt/local/lib/gcc47 --includedir=/opt/local/include/gcc47 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.7 --with-libiconv-prefix=/opt/local --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.7 --with-gxx-include-dir=/opt/local/include/gcc47/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --enable-stage1-checking --disable-multilib --enable-lto --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc47 4.7.1_0'
Thread model: posix
gcc version 4.7.1 (MacPorts gcc47 4.7.1_0) 
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.4' '-v' '-mtune=core2'
 /opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.1/cc1 -quiet -v -D__DYNAMIC__ iconv.c -fPIC -quiet -dumpbase iconv.c -mmacosx-version-min=10.7.4 -mtune=core2 -auxbase iconv -version -o /var/folders/qg/3j6tq6992rz3z7jxcx6xb7zc0000gn/T//cc483mGx.s
GNU C (MacPorts gcc47 4.7.1_0) version 4.7.1 (x86_64-apple-darwin11)
	compiled by GNU C version 4.7.1, GMP version 5.0.4, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.1/../../../../../x86_64-apple-darwin11/include"
ignoring duplicate directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include
 /opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.1/include
 /opt/local/include
 /opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.1/include-fixed
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
GNU C (MacPorts gcc47 4.7.1_0) version 4.7.1 (x86_64-apple-darwin11)
	compiled by GNU C version 4.7.1, GMP version 5.0.4, MPFR version 3.1.0-p3, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e759aa47287dbc2acfa8f39a5c501a74
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.4' '-v' '-mtune=core2'
 /opt/local/bin/as -v -arch x86_64 -force_cpusubtype_ALL -o /var/folders/qg/3j6tq6992rz3z7jxcx6xb7zc0000gn/T//cczNJZvo.o /var/folders/qg/3j6tq6992rz3z7jxcx6xb7zc0000gn/T//cc483mGx.s
Apple Inc version cctools-822, GNU assembler version 1.38
COMPILER_PATH=/opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.1/:/opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.1/:/opt/local/libexec/gcc/x86_64-apple-darwin11/:/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.1/:/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/
LIBRARY_PATH=/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.1/:/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.1/../../../:/usr/lib/
COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.7.4' '-v' '-mtune=core2'
 /opt/local/libexec/gcc/x86_64-apple-darwin11/4.7.1/collect2 -dynamic -arch x86_64 -macosx_version_min 10.7.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.10.6.o -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.1 -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.1/../../.. -liconv /var/folders/qg/3j6tq6992rz3z7jxcx6xb7zc0000gn/T//cczNJZvo.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v
collect2 version 4.7.1
/opt/local/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.7.4 -weak_reference_mismatches non-weak -o a.out -lcrt1.10.6.o -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.1 -L/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.1/../../.. -liconv /var/folders/qg/3j6tq6992rz3z7jxcx6xb7zc0000gn/T//cczNJZvo.o -no_compact_unwind -lSystem -lgcc_ext.10.5 -lgcc -lSystem -v
@(#)PROGRAM:ld  PROJECT:ld64-128.2
Library search paths:
	/opt/local/lib/gcc47/gcc/x86_64-apple-darwin11/4.7.1
	/opt/local/lib/gcc47
	/usr/lib
	/usr/local/lib
Framework search paths:
	/Library/Frameworks/
	/System/Library/Frameworks/

[jwiegley@…]

Cc Me!

[jwiegley@…]

Cc Me!

[kitchen.andy@…]

Hey, how's the new port been going for the people watching this issue?

I've been unable to reproduce cal's problems unfortunately, so I'd love to know if anyone else has had this problem or others so I can get them ironed out.

Regards

AK

[neverpanic (Clemens Lang)]

It works for me when using

compiler.cpath /usr/include
compiler.library_path /usr/lib

rather than

compiler.cpath /usr/include:${compiler.cpath}
compiler.library_path /usr/lib:${compiler.library_path}

I guess we can consider this problem solved then, since the resulting binaries are correctly linked against the libraries in $prefix.

A final thing: The binaries produced do execute correctly (I have no idea how to test them correctly, though), but are linked against two versions of libgcc_s:

/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1669.0.0)
/opt/local/lib/gcc45/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

Is this expected behavior and/or harmless?

[kitchen.andy@…]

Hi Cal,

Run the tests, they have been added to the latest portfile. GHC is a big project, so I think about a dozen or so unexpected test failures would be tolerable, depending where they are.

But if thousands of the tests are passing, we should be good to release.

Regards

AK

[neverpanic (Clemens Lang)]

Filed port abandonment ticket against ghc and ghc-devel in #35561. We need this resolved before I can commit the new port.

I'm currently running the testcases and will report back as soon as they have finished.

[neverpanic (Clemens Lang)]

OVERALL SUMMARY for test run started at Mon Aug  6 21:53:09 CEST 2012
    3160 total tests, which gave rise to
   13545 test cases, of which
       1 caused framework failures
   10701 were skipped

    2726 expected passes
      63 expected failures
       0 unexpected passes
      54 unexpected failures

Unexpected failures:
   cabal/cabal01             cabal01 [bad stderr] (normal)
   cabal/cabal04             cabal04 [bad stderr] (normal)
   codeGen/should_compile    2578 [bad stderr] (normal)
   driver                    driver062a [bad stderr] (normal)
   driver                    driver062b [bad stderr] (normal)
   driver                    driver062c [bad stderr] (normal)
   driver                    driver062d [bad stderr] (normal)
   driver                    driver062e [bad stderr] (normal)
   driver                    driver081a [bad stderr] (normal)
   driver                    driver081b [bad stderr] (normal)
   driver                    rtsopts001 [bad stderr] (normal)
   driver                    rtsopts002 [bad stderr] (normal)
   driver                    withRtsOpts [bad stderr] (normal)
   driver/1372               1372 [bad stderr] (normal)
   driver/1959               1959 [bad stderr] (normal)
   driver/437                437 [bad stderr] (normal)
   driver/T3007              T3007 [bad stderr] (normal)
   driver/objc               objc-hi [exit code non-0] (normal)
   driver/objc               objcpp-hi [exit code non-0] (normal)
   driver/recomp004          recomp004 [bad stderr] (normal)
   driver/recomp009          recomp009 [bad stderr] (normal)
   driver/recomp010          recomp010 [bad stderr] (normal)
   driver/recomp011          recomp011 [bad stderr] (normal)
   dynlibs                   T5373 [bad exit code] (normal)
   gadt                      gadt23 [bad stderr] (normal)
   hsc2hs                    3837 [bad exit code] (normal)
   hsc2hs                    hsc2hs001 [bad exit code] (normal)
   hsc2hs                    hsc2hs002 [bad exit code] (normal)
   hsc2hs                    hsc2hs003 [bad exit code] (normal)
   hsc2hs                    hsc2hs004 [bad exit code] (normal)
   lib/IO                    3307 [bad stderr] (normal)
   lib/IO                    environment001 [bad stderr] (normal)
   lib/integer               integerConstantFolding [bad stderr] (normal)
   module                    mod179 [stderr mismatch] (normal)
   module/mod175             mod175 [bad stderr] (normal)
   parser/should_compile     T5243 [stderr mismatch] (normal)
   perf/compiler             T1969 [stat not good enough] (normal)
   perf/compiler             T4801 [stat not good enough] (normal)
   perf/compiler             parsing001 [stat not good enough] (normal)
   perf/should_run           T2902 [bad stderr] (normal)
   perf/should_run           T3736 [bad stderr] (normal)
   plugins                   plugins01 [bad stderr] (normal)
   programs/hs-boot          hs-boot [stderr mismatch] (normal)
   rename/prog006            rn.prog006 [bad stderr] (normal)
   rts                       4850 [bad stderr] (normal)
   rts                       T4059 [bad stderr] (normal)
   rts                       T5423 [bad stderr] (normal)
   rts                       outofmem2 [bad stderr] (normal)
   safeHaskell/check         Check04 [stderr mismatch] (normal)
   safeHaskell/check/pkg01   safePkg01 [bad stderr] (normal)
   simplCore/should_compile  spec-inline [stderr mismatch] (optasm)
   th                        TH_Depends [bad stderr] (normal)
   th                        TH_spliceE5_prof [bad stderr] (normal)
   typecheck/bug1465         bug1465 [bad stderr] (normal)

I'm seeing a number of these:

gcc-mp-4.5: unrecognized option '-u'

Seems reasonable enough to me.

[fmgolmedo@…]

Cc Me!

[mikesmithso@…]

Cc Me!

[lemieud@…]

Cc Me!

[jowens@…]

Cc Me!

[kitchen.andy@…]

Test output seems reasonable enough to me too, is there anything else that I should do now?

Also, I personally need this patch:

​http://hackage.haskell.org/trac/ghc/ticket/7040

Should I add it to the port or keep it separate? It fixes a reasonably large bug on Mac OS X.

Regards

AK

[jean-philippe.humbert@…]

Cc Me!

[neverpanic (Clemens Lang)]

I'm only waiting for #35561 to commit the Portfile.

The maintainer line has a FIXME: Do you want to be listed? You can also add my MacPorts handle, if you want. Do you want to make the port openmaintainer (see ​http://guide.macports.org/#project.update-policies for an explanation).

Feel free to add the patch to the port.

[kitchen.andy@…]

Sure, I'll be listed as maintainer, openmaintainer sounds good.

I've noticed that ghc compiled with gcc45 really spits out a lot of angry warnings where as gcc47 seems to work a lot smoother. Maybe we should make the default variant +gcc47?

Regards

AK

[geekosaur]

Wait, ghc 7.4.2? Are we joining the list of folks who figure abandoning the Haskell Platform that is the standard Haskell development target is somehow a good idea?

[me@…]

Cc Me!

[me@…]

Cc Me!

[me@…]

Cc Me!

[me@…]

Cc Me!

[me@…]

Cc Me!

[neverpanic (Clemens Lang)]

In a discussion in IRC, Brandon suggests we stick to what is shipped in the Haskell Platform package, as this is what upstream encourages to ship. This would mean installing ghc 7.4.1 and updating a number of other packages at the same time:

​http://hackage.haskell.org/platform/changelog.html

The affected packages would be:

• haskell-platform
• hs-platform-cgi
• hs-platform-fgl
• hs-platform-editline
• hs-platform-GLUT
• hs-platform-haskell-src
• hs-platform-html
• hs-platform-HUnit
• hs-platform-mtl
• hs-platform-network
• hs-platform-OpenGL
• hs-platform-parallel
• hs-platform-parsec
• hs-platform-QuickCheck
• hs-platform-regex-base
• hs-platform-regex-compat
• hs-platform-regex-posix
• hs-platform-stm
• hs-platform-time
• hs-platform-xhtml
• hs-platform-zlib
• hs-platform-HTTP
• hs-platform-alex
• hs-platform-happy
• hs-platform-cabal

It seems those updates would be pretty straightforward.

[raimue (Rainer Müller)]

Port abandoned, #35561.

[kitchen.andy@…]

Replying to allbery.b@…:

Wait, ghc 7.4.2? Are we joining the list of folks who figure abandoning the Haskell Platform that is the standard Haskell development target is somehow a good idea?

Hi allbery, please be more polite, I have spent a quite a few precious Sunday afternoons getting the kinks ironed out of these port files for you and other haskell users. Considering how much work needs to be done, tracking the haskell platform is not a priority for me at this time. Perhaps if the haskell platform is important to you, you can spend some time updating the ports from the list that cal has generously provided.

[kitchen.andy@…]

Replying to cal@…:

In a discussion in IRC, Brandon suggests we stick to what is shipped in the Haskell Platform package, as this is what upstream encourages to ship. This would mean installing ghc 7.4.1 and updating a number of other packages at the same time: It seems those updates would be pretty straightforward.

Hi Cal,

From a utilitarian perspective I don't think tracking the Haskell Platform is the best use of resources, basically I think what is most sorely missing is a high quality package that tracks the normal ghc releases with some patches to keep things ticking along.

I don't see the logic in holding back a bugfix release, a large virtue of a package management system with auto updating is that bugfixes can be pushed down stream quickly and easily.

I see three basic demographics, people who need nothing more than the platform can use the official .pkg releases. People who develop ghc can compile straight form source tarballs, possibly using the macports ghc as a bootstrap compiler. Which leaves people in the middle who need a high quality GHC release for development where bugs are fixed reasonably quickly.

One major benefit of the haskell platform is the stable base it provides and I think that this is best serviced by the haskell platform .pkg releases. The macports ghc is going to be linked against different libraries and compiled by a different compiler, so this removes one of the major benefits of the haskell platform.

I think that a future project to closely mirror the haskell platform in macports is an ok idea, but should be low priority because there is already a reasonably high quality haskell platform release.

My suggestion would be to drop ghc-devel, make the ghc package track the normal stable releases and add ad new hs-platform-ghc that conflicts with ghc that can be kept down at whatever the platform release is. We can also hold off patching the hs-platform-ghc so that users can be sure exactly what bugs they will get too.

[neverpanic (Clemens Lang)]

I hardly know the Haskell community, so I'll have to rely on what people are telling me. I can just comment on the MacPorts side of things here.

I think we can move the current state of the ghc port into hs-platform-ghc, mark it conflicting with ghc, replace the dependencies in the hs-platform packages and update ghc. This would preserve the current state of the haskell-platform packages in MacPorts (although I'm not sure it's worth the effort, because I don't know whether anybody still uses haskell-platform 2009.2.0.2).

I also think using gcc47 as the default variant is justified, because it causes less test failures.

Meanwhile, I've forked the haskell-platform and hs-platform-* packages into my private repository to work on updating them. If you want to help out, have a look at source:/users/cal/ports/devel.

Can you submit a version of the Portfile with the maintainer and default variant changed? I've been modifying my copy locally and have lost track of the diffs to the versions discussed here.

[daitakahashi]

Cc Me!

[kitchen.andy@…]

Replying to cal@…:

I hardly know the Haskell community, so I'll have to rely on what people are telling me. I can just comment on the MacPorts side of things here.

I find the community can be a bit risk adverse sometimes. I think it's best to have fast rolling releases.

I think we can move the current state of the ghc port into hs-platform-ghc, mark it conflicting with ghc, replace the dependencies in the hs-platform packages and update ghc. This would preserve the current state of the haskell-platform packages in MacPorts (although I'm not sure it's worth the effort, because I don't know whether anybody still uses haskell-platform 2009.2.0.2).

I also think using gcc47 as the default variant is justified, because it causes less test failures.

Meanwhile, I've forked the haskell-platform and hs-platform-* packages into my private repository to work on updating them. If you want to help out, have a look at source:/users/cal/ports/devel.

I've already updated enough packages to get the newest version of cabal-install through macports, I'll attach those files as well.

Can you submit a version of the Portfile with the maintainer and default variant changed? I've been modifying my copy locally and have lost track of the diffs to the versions discussed here.

Done, I would really like commit access, because I've just updated a bunch of octave ports as well.

Regards

AK

[kitchen.andy@…]

updated hs-cabal and supporting ports

[kitchen.andy@…]

GHC 7.4.2 portfile with gcc47 as default variant and maintainer added

[fmgolmedo@…]

Dear A. Kitchen

From the last posts I understand that the ports have been updated "hs-cabal" and "ghc".

I'm using Haskell, MacPorts and iMac now on Lion Mountain. Using Xcode 4.4.1 I've updated.

Today I tried to install the ports mentioned above and I could not, because they depend on perl5.8 and the process fails when trying to install perl5.8.

Is there any possible solution to this costly problem?

I attached my "main.log" and the dialogue of the console.

imac-de-user:~ my_user$ sudo port install ghc
--->  Computing dependencies for ghc
--->  Dependencies to be installed: perl5.8
--->  Fetching archive for perl5.8
--->  Attempting to fetch perl5.8-5.8.9_8.darwin_12.x86_64.tbz2 from http://packages.macports.org/perl5.8
--->  Fetching distfiles for perl5.8
--->  Verifying checksum(s) for perl5.8
--->  Extracting perl5.8
--->  Applying patches to perl5.8
--->  Configuring perl5.8
--->  Building perl5.8
Error: org.macports.build for port perl5.8 returned: command execution failed
Error: Failed to install perl5.8
Please see the log file for port perl5.8 for details:
    /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_perl5.8/perl5.8/main.log
Error: The following dependencies were not installed: perl5.8
To report a bug, follow the instructions in the guide:
    http://guide.macports.org/#project.tickets
Error: Processing of port ghc failed
imac-de-user:~ my_user$ 

We greatly appreciate your attention.

fmgo

[neverpanic (Clemens Lang)]

The ports mentioned have not been updated yet; it has only been discussed, but there was no commit updating them yet.

The new port will not depend on perl5.8. Please, do not hijack this bug for something unrelated but use one of the existing tickets for this problem (which has, btw, been fixed 6 days ago in r96453).

[neverpanic (Clemens Lang)]

I just

• Copied the current state of the ghc port to hs-platform-ghc (r96876)
• Added (automatic) upgrade path for users of haskell-platform by deactivating ghc (r96880)
• Changed haskell-platform to depend on hs-platform-ghc rather than ghc (r96881)

You didn't provide a copy of ghc7040.patch and the upstream one does not apply correctly in MacPorts (try: port -d patch ghc).

[neverpanic (Clemens Lang)]

Nevermind, the fix was an easy one.

Commited in r96883.

On your devel.tar.gz, I'll have a look soon, but some of the ports in there are not openmaintainer or nomaintainer and I can't thus just update them per our update policies (​http://guide.macports.org/#project.update-policies). I'll try to update those that are open- or nomaintainer, but for the others, we'll need to file tickets.

I still haven't touched the ghc-devel port. Should I mark it obsolete and transition it to the ghc port for now?

Thanks for your work so far.

[neverpanic (Clemens Lang)]

Oh, and commenting on:

Done, I would really like commit access, because I've just updated a bunch of octave ports as well

Please read ​http://guide.macports.org/#project.membership. You having commit access would probably simplify (and speed up) updating the auxiliary haskell ports a lot.

[neverpanic (Clemens Lang)]

Forgot the ghc-bootstrap port. Commited in r96892 and r96893. I've also added you to the maintainers of this port.

[kitchen.andy@…]

I still haven't touched the ghc-devel port. Should I mark it obsolete and transition it to the ghc port for now?

ghc bleeding-edge is really for ghc developers only, almost nothing from cabal really works meaning that it's almost useless for other development. So yeah, definitely mark ghc-devel as obsolete.

Thanks for your work so far.

Thank you cal, people like you make me want to contribute more to MacPorts.

Also, I'm muchly embarassed, but I just got some build failure warnings from the macports buildbot, I realised that I accidentally set parallel compiles on in the port I posted, this is wrong, it should definitely be off.

Again, my apologies about that and also about the patch.

On your devel.tar.gz, I'll have a look soon, but some of the ports in there are not openmaintainer or nomaintainer and I can't thus just update them per our update policies ( ​http://guide.macports.org/#project.update-policies). I'll try to update those that are open- or nomaintainer, but for the others, we'll need to file tickets.

Ok, I'll post the ticket right now (I'll just do one for all the updates) Let's do it reasonably quickly because without cabal-install (hs-cabal) ghc is useless for real development.

Kind Regards

AK

[kitchen.andy@…]

Ticket for hs-cabal update:

​https://trac.macports.org/ticket/35762

[neverpanic (Clemens Lang)]

Replying to kitchen.andy@…:

So yeah, definitely mark ghc-devel as obsolete.

OK, I'll be doing that tonight or tomorrow.

Also, I'm muchly embarassed, but I just got some build failure warnings from the macports buildbot, I realised that I accidentally set parallel compiles on in the port I posted, this is wrong, it should definitely be off.

The build failure you got occurred because I forgot to commit ghc-bootstrap. I triggered a rebuild after I commited that and it went through just fine (​SL Buildbot, ​Lion Buildbot, ​Package Server).

I can still turn parallel builds off, if you want.

Let's do it reasonably quickly because without cabal-install (hs-cabal) ghc is useless for real development.

I'll also try to have a look tonight or tomorrow.

[neverpanic (Clemens Lang)]

ghc-devel marked obsolete in r96921. I think we can consider this ticket resolved now.

[evandrix (Lee Wei Yeong)]

Cc Me!