|Summary:||lang/mlton: when built with GCC 4.8 fails to compile lang/urweb|
|Product:||Ports & Packages||Reporter:||Gerald Pfeifer <gerald>|
|Component:||Individual Port(s)||Assignee:||Timothy Beyer <beyert>|
|Severity:||Affects Only Me||CC:||beyert, cmt|
|Bug Depends on:|
Description Gerald Pfeifer 2014-07-26 15:17:48 UTC
We are working to change the default version of GCC from 4.7 (which is end of life) to 4.8, cf. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192025 This port is one of a handful that blocks this transition. lang/urweb, when built with lang/mlton as built with GCC 4.8 fails as follows: mlton -mlb-path-var 'SRC /wrkdirs/usr/ports/lang/urweb/work/urweb-20140704/src' -mlb-path-var 'BUILD /wrkdirs/usr/ports/lang/urweb/work/urweb-20140704/src' -output bin/urweb src/compiler.mlb gmake: *** [bin/urweb] Killed http://package23.nyi.freebsd.org/data/10amd64-default-PR192025/2014-07-24_23h12m00s/logs/errors/urweb-20140704.log has the full logs.
Comment 1 Antoine Brodin 2014-07-26 21:52:41 UTC
I relaunched it and it succeeded this time: http://package23.nyi.freebsd.org/data/10amd64-default-PR192025/2014-07-26_21h30m19s/logs/urweb-20140704.log
Comment 2 Timothy Beyer 2014-07-26 22:59:36 UTC
It works for me on GCC 4.8, but I did notice that when USE_GCC= any is used, on my system it compiles with gcc46. As soon as I got rid of that directive, it worked fine with gcc48. I am going to verify if it compiles with clang to see if I can remove the USE_GCC macro. I can say for certain that gcc48 works, at least in the case that both lang/mlton and lang/urweb are compiled with gcc48.
Comment 3 Gerald Pfeifer 2014-07-27 16:36:15 UTC
(In reply to Timothy Beyer from comment #2) > It works for me on GCC 4.8, but I did notice that when USE_GCC= any is > used on my system it compiles with gcc46. That should only happen if lang/gcc46 is installed and lang/gcc48 is not. Was that the case on your system, or do we have something to look into from this perspective. > As soon as I got rid of that directive, it worked fine with gcc48. > > I am going to verify if it compiles with clang to see if I can remove the > USE_GCC macro. Sounds good. If you want to stay with GCC, I do recommend USE_GCC=yes over USE_GCC=any since that rules out the ancient system compiler on older versions of FreeBSD and makes things more consistent across releases. (I guess you can go ahead and close this bug report, though it would be great if you could update it with your findings and next steps, even if not addressing a real bug. Thank you!)
Comment 4 Timothy Beyer 2014-07-27 18:30:58 UTC
Here are the versions of gcc that I have installed: [[code format="sh"]] # pkg query -x "%n-%v %C/%n" "gcc" gcc-4.7.3_1 lang/gcc gcc-4.7.3_1 java/gcc gcc-ecj-4.5 lang/gcc-ecj gcc-ecj-4.5 java/gcc-ecj gcc34-3.4.6_3,1 lang/gcc34 gcc46-4.6.4_1,1 lang/gcc46 gcc46-4.6.4_1,1 java/gcc46 gcc48-4.8.4.s20140626 lang/gcc48 gcc48-4.8.4.s20140626 java/gcc48 gccmakedep-1.0.2_1 devel/gccmakedep mingw32-gcc-4.7.2_1,1 devel/mingw32-gcc [[code]] I can compile lang/mlton with any version of gcc that I tried, but when I comment out USE_GCC, and set clang as CC in /etc/make.conf, it gives an error: [[code]] clang: error: unsupported option '-gstabs+' [[code]] I'm not sure if mlton has support for non-gcc compilers yet, but I do know that there is a student making an LLVM backend for the compiler.
Comment 5 Gerald Pfeifer 2014-07-27 20:36:36 UTC
(In reply to Timothy Beyer from comment #4) > gcc34-3.4.6_3,1 lang/gcc34 This is no longer in the tree; unless you really need it, I'd remove it. > gcc46-4.6.4_1,1 lang/gcc46 > gcc46-4.6.4_1,1 java/gcc46 This is still in the tree, but should only be used by one or two ports; I suggest to remove it unless you really need it. > I can compile lang/mlton with any version of gcc that I tried, but when I > comment out USE_GCC, and set clang as CC in /etc/make.conf, it gives an > error: > > [[code]] > clang: error: unsupported option '-gstabs+' > [[code]] That indeed implies that for now GCC is necessary.
Comment 6 Timothy Beyer 2014-07-27 20:57:38 UTC
I guess that gcc 3.4 were installed a long time ago, as I couldn't find any ports that depend on those versions. I uninstalled both without incident. I'll look into the next released version of mlton (2013 version), which might have support for more compilers, although I think that the upcoming 2014 release is the one that officially supports llvm.
Comment 7 Antoine Brodin 2014-08-06 08:25:55 UTC
Close, it successfully build on 2nd run