[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #17 from Eric Botcazou --- Author: ebotcazou Date: Wed Apr 25 10:01:55 2018 New Revision: 259640 URL: https://gcc.gnu.org/viewcvs?rev=259640&root=gcc&view=rev Log: PR ada/85007 * gnat_ugn.texi: Regenerate. Modified: branches/gcc-8-branch/gcc/ada/ChangeLog branches/gcc-8-branch/gcc/ada/gnat_ugn.texi
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #16 from Eric Botcazou --- Author: ebotcazou Date: Wed Apr 25 10:01:13 2018 New Revision: 259639 URL: https://gcc.gnu.org/viewcvs?rev=259639&root=gcc&view=rev Log: PR ada/85007 * gnat_ugn.texi: Regenerate. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gnat_ugn.texi
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |WONTFIX --- Comment #15 from Eric Botcazou --- The switch will be removed in GCC 8 and later.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #14 from Eric Botcazou --- Author: ebotcazou Date: Fri Mar 23 23:20:59 2018 New Revision: 258828 URL: https://gcc.gnu.org/viewcvs?rev=258828&root=gcc&view=rev Log: PR ada/85007 * gnatlink.adb (Gnatlink): Remove handling of -b switch. * doc/gnat_ugn/building_executable_programs_with_gnat.rst (gnatlink): Remove documentation of -b switch. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst trunk/gcc/ada/gnatlink.adb
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #13 from Eric Botcazou --- > It looks from gnatlink.adb:540 (of 7.3.0), if the "--GCC=" flag is > specified, it short-circuits all other args that normally would have been > passed to the linker, including the optimization level, "-m32", "--RTS=32", > and any other flags that were passed in the compiler section of the GPR file. Right, historical quirk, but we're not going to change that now.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #12 from Eric Reischer --- It's in there on my target system; I just missed it when I was transcribing over into the report. It looks from gnatlink.adb:540 (of 7.3.0), if the "--GCC=" flag is specified, it short-circuits all other args that normally would have been passed to the linker, including the optimization level, "-m32", "--RTS=32", and any other flags that were passed in the compiler section of the GPR file.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #11 from Eric Botcazou --- > The gcc configure line was taken directly from the Debian distribution > package build script. Distros frequently allow having multiple versions of > gcc installed, and give them the appropriate extension via the > "--program-suffix" argument to the configure command. I don't see --program-suffix in your configure line though.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #10 from Eric Reischer --- The gcc configure line was taken directly from the Debian distribution package build script. Distros frequently allow having multiple versions of gcc installed, and give them the appropriate extension via the "--program-suffix" argument to the configure command. They will frequently provide symlinks to the root program names (gcc -> gcc-7.3) for convenience, but one would argue the tools shouldn't depend on that (the root gcc, g++, etc., don't suffer from that issue, calling their helper programs by prepending the libexecdir config setting prior to executing the tools.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #9 from Eric Botcazou --- > I intend to use the 7.3 tree of "gcc-7.3" to do my compilation rather than > the system-search-provided "gcc". gnatmake-7.3 doesn't seem to want to use > the "gcc-7.3" provided in the same folder as it, so I had to manually > provide "--GCC=" on the gnatmake command line. That's the misconfiguration. Where does this -7.3 come from? It's possible to use this setup since Linux distributions do it but this must be done properly.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007
--- Comment #8 from Eric Reischer ---
N/M -- I found the trigger.
I intend to use the 7.3 tree of "gcc-7.3" to do my compilation rather than the
system-search-provided "gcc". gnatmake-7.3 doesn't seem to want to use the
"gcc-7.3" provided in the same folder as it, so I had to manually provide
"--GCC=" on the gnatmake command line. This worked as expected. However, this
argument was not passed onto the gnatlink command, so I provided it in the GPR
file:
package Linker is
for Default_Switches ("Ada")
use ("-v","--for-linker=-Map","--for-linker="driver.map",
"--GCC=/path/to/gcc-7.3/bin/gcc-7.3");
end Linker;
When you add in the "--GCC" to the linker arguments in the GPR file, it calls
"gcc-7" (I'm unable to determine if it's actually calling my gcc-7.3, or if the
"." is causing it to trip up, and it's terminating the argument there), and
doesn't pass in the "-m32" flag.
If I leave out the "--GCC" argument from the GPR file, it compiles and links
successfully, and passes in the correct arguments to gcc to compile the binder
file (and curiously enough, the ALI file doesn't have the x86-64 line), but it
uses the default system gcc, not the one passed to gnatmake.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #7 from Eric Reischer --- To make it easier to track down, can you post your configure line?
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #6 from Eric Botcazou --- > The multilib switch (-m32 -- which is undocumented as being valid for > gnatmake incidentally) Well, like the dozens of -f and -m switches accepted by the compiler and documented in the GCC manual. What would be the point of duplicating that? > It should be noted that at the top of the b~driver.ali file generated are > the following lines: > > V "GNAT Lib v7" > A -gnatA > A -gnatWb > A -gnatiw > A -g > A -gnatws > A -mtune=nehalem > A -march=x86-64 > P ZX > > As noted in the OP, my --with-tune=nehalem explains that line, but the > -march line shouldn't be appearing if --RTS=32 is being passed, correct? Yes, something appears misconfigured. Here's what I have: eric@polaris:~> ~/install/gcc-7-branch/bin/gnatmake p -m32 gcc -c -m32 --RTS=32 p.adb gnatbind --RTS=32 -x p.ali gnatlink p.ali -m32 eric@polaris:~> cat p.ali V "GNAT Lib v7" M P W=b A -m32 A --RTS=32 P ZX [...] eric@polaris:~> file p p: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux.so.2, for GNU/Linux 3.0.0, not stripped eric@polaris:~> ~/install/gcc-7-branch/bin/gnatmake --version GNATMAKE 7.3.1 20180316 [gcc-7-branch revision 258591] Copyright (C) 1995-2017, Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #5 from Eric Reischer --- The multilib switch (-m32 -- which is undocumented as being valid for gnatmake incidentally) already is being passed to "gnatmake" -- it properly passes this flag to gcc when compiling the spec and body files, along with the "--RTS" flag properly set. The gnatbind command generated (and output) is: gnatbind-7.3 -E -ws -v --RTS=32 -x driver.ali gnatbind-7.3 -E -ws -v --RTS=32 -F=GNAT-TEMP-04.TMP -x driver.ali GNATBIND 7.3.0 Copyright (C) 1995-2017, Free Software Foundation, Inc. Binding: driver.ali No errors - It should be noted that at the top of the b~driver.ali file generated are the following lines: V "GNAT Lib v7" A -gnatA A -gnatWb A -gnatiw A -g A -gnatws A -mtune=nehalem A -march=x86-64 P ZX As noted in the OP, my --with-tune=nehalem explains that line, but the -march line shouldn't be appearing if --RTS=32 is being passed, correct? The gnatlink command generated (and output) is: gnatlink-7.3 driver.ali -g -v --GCC=gcc-7.3 -m32 -o driver GNATLINK 7.3.0 Copyright (C) 1994-2017, Free Software Foundation, Inc. gcc-7 -c -gnatA -gnatWb -gnatiw -g -gnatws b~driver.adb gcc-7.3 b~driver.o -m32 -o driver ld: i386:x86-64 architecture of input file `b~driver.o' is incompatible with i386 output ld: b~driver.o: file class ELFCLASS64 incompatible with ELFCLASS32 ld: final link failed: File in wrong format So, the "-m32" multiarch flag is not being passed to the first tool command executed by gnatlink (gcc-7) to compile b~driver.adb, even though "-m32" is passed as an argument to gnatmake.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #4 from Eric Botcazou --- > Is there a new recommended way to get gnatlink to generate a 32-bit bind > file and link object on MULTIARCH systems (x86/x86_64 in this specific > case)? It seems this would be functionality that would be needed by others, > as well as needing a way to cross-compile for target hardware. That's not sufficient though, the entire toolchain must be configured either with multilib/multiarch or as a cross toolchain; IOW fiddling only with gnatlink does not work. For multilib/multiarch, you need to pass the multilib switch to 'gnatmake'. For a cross target, you need to configure the compiler as a cross compiler and the gnattools will automatically follow.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 --- Comment #3 from Eric Reischer --- No, it used gnatmake -P . Is there a new recommended way to get gnatlink to generate a 32-bit bind file and link object on MULTIARCH systems (x86/x86_64 in this specific case)? It seems this would be functionality that would be needed by others, as well as needing a way to cross-compile for target hardware.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 Eric Botcazou changed: What|Removed |Added Status|WAITING |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #2 from Eric Botcazou --- The option has been broken for a long time and will be removed.
[Bug ada/85007] -b flag to gnatlink not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85007 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-03-21 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- Is that with GPRbuild? If so, then it's misconfigured.
