The current package for 10.1-amd64 uses gcc47 at runtime, but does not depend on it. Example successful build after install gcc47 package: MLton 20100608 (built Wed Aug 20 23:44:59 UTC 2014 on 10amd64-default-job-01) MLton starting Compile SML starting pre codegen starting pre codegen finished in 42.05 + 16.71 (28% GC) amd64 code gen starting amd64 code gen finished in 97.93 + 14.95 (13% GC) Compile SML finished in 139.98 + 31.66 (18% GC) Compile and Assemble starting gcc47 -std=gnu99 -c -I/usr/local/lib/mlton/targets/self/include \ -I/usr/local/lib/mlton/include -O1 -fno-common -fno-strict-aliasing \ -fomit-frame-pointer -w -m64 -I/usr/local/include -o \ /tmp/fileX2jhBP.o /tmp/fileyWRtDs.13.c gcc47 -c -m64 -o /tmp/file59kEO8.o /tmp/fileUXL5yl.12.s gcc47 -c -m64 -o /tmp/file7PArD4.o /tmp/filekwi0rg.11.s gcc47 -c -m64 -o /tmp/filewvgKk0.o /tmp/fileNxZJea.10.s gcc47 -c -m64 -o /tmp/filef1paLo.o /tmp/fileMpnhKl.9.s gcc47 -c -m64 -o /tmp/fileFQS00N.o /tmp/filexRsUNL.8.s gcc47 -c -m64 -o /tmp/filehJpXa6.o /tmp/filebMM2uL.7.s gcc47 -c -m64 -o /tmp/fileP6ffb5.o /tmp/filegPcCCh.6.s gcc47 -c -m64 -o /tmp/fileaxVOju.o /tmp/file8z5ou9.5.s gcc47 -c -m64 -o /tmp/fileFGbAxw.o /tmp/fileh1MWWg.4.s gcc47 -c -m64 -o /tmp/files21e5H.o /tmp/filevRyAoY.3.s gcc47 -c -m64 -o /tmp/fileblq4Bk.o /tmp/file89dfec.2.s gcc47 -c -m64 -o /tmp/filegSEWZf.o /tmp/fileFK3rBB.1.s gcc47 -c -m64 -o /tmp/fileAx5QDt.o /tmp/fileZPhCzU.0.s Compile and Assemble finished in 6.41 + 0.00 (0% GC) Link starting gcc47 -o l3mips-cheri128 /tmp/fileX2jhBP.o /tmp/file59kEO8.o \ /tmp/file7PArD4.o /tmp/filewvgKk0.o /tmp/filef1paLo.o \ /tmp/fileFQS00N.o /tmp/filehJpXa6.o /tmp/fileP6ffb5.o \ /tmp/fileaxVOju.o /tmp/fileFGbAxw.o /tmp/files21e5H.o \ /tmp/fileblq4Bk.o /tmp/filegSEWZf.o /tmp/fileAx5QDt.o \ -L/usr/local/lib/mlton/targets/self -lmlton -lgdtoa -lm -lgmp -m64 \ -L/usr/local/lib/ Link finished in 0.14 + 0.00 (0% GC) MLton finished in 148.03 + 31.68 (18% GC)
Does the USE_GCC macro not suffice, or is that only for establishing a runtime dependency?
(In reply to Timothy Beyer from comment #1) USE_GCC only sets up a build dependency.
I will experiment with using ${CC} at runtime. If the current version requires gcc, then later versions are likely to be less dependent. There is an LLVM code generator in later versions, which is reported in the Mlton wiki to produce smaller binaries and faster executables.
Created attachment 159798 [details] use version of lang/gcc for RUN_DEPENDS Also fixes some typos
I just uploaded a patch that uses the version of gcc of lang/gcc in RUN_DEPENDS (executable version number derived from ${LANG_GCC_IS}, but with the dot stripped). Let me know if this will suffice towards the runtime requirement.
Brooks, can you confirm if Timothy's patch works for you?
If there is anything wrong with that is preventing inclusion, I will be happy to sort out any issues. It's been hard for me to do rigorous testing on my ports because I used to depend on redports, which AFAIK wasn't available at the time I submitted this patch. I'd like to start using poudriere for my future submissions, although that doesn't address the issue that I don't have an easy means to test on other hardware.
I just set maintainer-feedback to +, I was unaware of these flags until recently. My apologies. If an updated version of my submission is needed, please let me know. Thanks!
The ball is on Brooks's court at the moment, you've done everything correctly. I could just commit your patch, but comment #2 doesn't look right to me. bsd.gcc.mk already has logic in it to add GCC as both a build- and run-time dependency. In fact, if I do `make -C /usr/ports/lang/mlton run-depends-list' without applying the patch attached to this bug I can see lang/gcc in the list. It's thus unclear to me if there's a problem to fix in the first place.
It looks like this issue is OBE. The port does indeed correctly depend on gcc48 and that is the compiler mlton uses. Thanks for working on this. Sorry I haven't been responsive.