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

[Massimo Dentico]

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:

    -Wl,--stack=8388608

[For people not familiar with this flag: it's passing linker flags
from GCC to the linker. See:
    https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html#index-Wl
]

On my system:

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

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

    https://sourceware.org/binutils/docs-2.34/ld/Options.html

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