[m-users.] Compiler build failure with --enable-lto

Massimo Dentico m.dentico at virgilio.it
Mon Jun 15 11:08:54 AEST 2020

On 15/06/2020 00:31, M McDonough wrote:
> Yeah, something is wrong there, although I don't really know what
> (maybe we need different flags for ar, or to fiddle with whole-archive
> settings, or one of the "prune" sections flags?). I mostly tested on
> MSVC to make sure it worked, and Clang on OpenBSD to make sure it at
> least compiled. I didn't try to use it with GCC on Windows at all.
> It's most reliable on Windows with MSVC at this point, although it
> would be great if it did work with GCC on Windows :(

This line caught my attention:

../scripts/ml --grade asm_fast.gc    --no-mercury-stdlib-dir --shared 
--trace-init-file ../browser/mer_browser.init --ssdb-init-file 
../ssdb/mer_ssdb.init        -- -Wl,--stack=8388608   -o 
mercury_compile.exe mercury_compile_init.o \

The syntax of this flag in particular:


[For people not familiar with this flag: it's passing linker flags
from GCC to the linker. See:

On my system:

    $ ld --version
    GNU ld (GNU Binutils) 2.34

So let's look at the binutils documentation for this version of ld:


The stack size is specified in this way (emphasis added):

    --stack reserve
    --stack reserve,commit
       Specify the number of bytes of memory to reserve (and optionally
       commit) to be used as stack for this program. The default is 2MB
       reserved, 4K committed. [This option is specific to the i386 *PE*
       targeted port of the linker]

For Windows the executable format is Portable Executable (PE), so that
syntax doesn't seem correct. Or I'm missing something?

I hope this is helpful. Ok, it's late night here, I need to sleep.

Massimo A. Dentico

More information about the users mailing list