Re: Keep MLton from being kicked out of Debian?

On Mon, Nov 7, 2016 at 4:55 PM, Christopher Cramer
<[email protected]> wrote:
> On Mon, Nov 07, 2016 at 04:38:44PM -0500, Matthew Fluet wrote:
>> You could add it to the `mlton/Makefile` where it detects compiling
>> with an older version:
>>   https://github.com/MLton/mlton/blob/master/mlton/Makefile#L40
>> You could add a
>>   FLAGS += -cc-opt -fno-pie -link-opt -fno-pie
>
> Yeah, I did exactly that (and also had to stick it into bin/upgrade-basis).

Make sense.  I've killed bin/upgrade-basis in master, because it is a
pain (and hasn't really done anything for quite some time).

> But the next problem I'm having is that the self-compiling stage
> isn't working:
>
> Compiling mllex
> "mlton" -target self mllex.mlb
> /usr/bin/ld: /tmp/fileM3o02U.o: relocation R_X86_64_32S against `.data' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: /tmp/fileuuCnoI.o: relocation R_X86_64_32S against `.data' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> call to system failed with exit status 1:
> gcc -o mllex /tmp/filepfaQ8o.o /tmp/fileofptQJ.o /tmp/fileM3o02U.o /tmp/fileuuCnoI.o -L/home/tsuyoshi/src/mlton-20100608/build/lib/targets/self -lmlton -lgdtoa -lm -lgmp -m64 -Wl,-znoexecstack
>
> Does the mlton codegen support PIC, or do we just need to disable it?
> I remember we ran into this problem on OSX before, and I believe that's
> what you use, so what did you do for OSX?

MLton supports PIC, it just does not assume that Linux requires PIC.
Debian might patch to force using PIC; should be as simple as adding a
case to:
  https://github.com/MLton/mlton/blob/master/mlton/main/main.fun#L920

Of course, if you make that patch, then MLton will always generate PIC.

And, this is where I haven't figured out what Debian is trying to
achieve.  Is the PIC/PIE default gcc just during package building (so
that executables within .deb packages are PIE), or is it also the
behavior of an installed Debian system, so that a normal user invoking
gcc will get the PIC/PIE default?  If the behavior of an installed
Debian system is not to have a PIC/PIE default gcc, then you will end
up with the awkward situation where MLton will (unnecessarily)
generate PIC code, although I don't think it a problem if PIC object
is linked with non-PIC objects into a non-PIE executable.

MLton should really support some kind of "-pie {false|true}" flag,
whose default depends on the target platform.  But, by "target
platform", we need something more specific than our past arch/os pair
--- because amd64-linux Debian sid wants the default to be true, but
amd64-linux Debian jessie wants (or at least allows) the default to be
false, and other linux distros also allow the default to be false.
Ideally, we would generate PIC/non-PIC assembly depending on the
default behavior of the C compiler on the target and similarly link
PIE/non-PIE depending on the default behavior, with options to
override the default (passing the appropriate flags to the C
compiler).

-- 
You received this message because you are subscribed to the Google Groups "MLton-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi