Closed Alex-Gamper closed 5 years ago
Hi Alex,
I assume that I would probably be better of installing two compilers (x86 and x64) and using the appropriate target ?
Long story short, that's indeed the only thing we know how to support, both on compiler level and builder level. If you manage to get it to work with multilib compilers, we will be happy to look at a pull request.
want to ask same question too...
in my case my multilib gcc target 32-bit by default (sjlj)
as workaround I use following -largs
to target 64-bit (seh):
-m64 -L$(dirname $(gcc -m64 -print-libgcc-file-name))/adalib -lgnat -lgnarl
it works fine when compiling GWindows
specs: msys2 gcc 10.3 + mingw-w64 9.0 gprbuild 2021 windows xp
If -largs hack is the only thing that's necessary it can probably be set up as a knowledge base snippet by assigning the necessary options to Switches/Leading_Switches/Trailing_Switches as appropriate.
as Alex-Gamper said -cargs also set to -m64/-m32 respectively, and it assumed that gcc is configured with --enable-version-specific-runtime-libs
too bad gcc -m64 -print-file-name=libgnat.a
wont work for gnat.
Can Gprbuild be used/configured to use a multilib capable compiler running under msys2 ?
I know I can set the -m32 switch for the compiler and binder via -cargs and -bargs which produces a 32bit object files, BUT the linker complains and I cant seem to link due to unresolved references to libgnat/libgnarl, since the linker is looking at the native x64 directories by default. Is their a switch to tell the linker to use the 32 directories instead of the default
Note: If I setup a symlink rts-32 pointing to the\32 directory, I then get unresolved references
to libgcc when invoking gprbuild with --RTS=32 (I wasn't expecting this to work, but it was worth
a try :-) )
Any guidance would be appreciated
I assume that I would probably be better of installing two compilers (x86 and x64) and using the appropriate target ?
Thanks
Alex