I wanted to upgrade to binutils 2.26 , so i followed the steps here : How to convert default binutils into binutils-2.26? to solve the same "unrecognized relocation" error.
Now my default linker is 2.26
$ ld --version
GNU ld (GNU Binutils for Ubuntu) 2.26.1
Copyright (C) 2015 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
But "make" still uses the "/usr/bin/x86_64-linux-gnu-ld" (which is 2.24) and still gives the same error.
So how to force "make" to use the default linker ?
It depends upon your Makefile (which you could debug with remake -x). Notice that make has a lot of builtin rules. Use make -p to also print them. Notice the rules mentioning LINK.c or LINK.cc etc, and notice that LD is not much used. Notice also that ld is almost never used directly (most of the time, some other program like gcc or g++ runs it).
And it is also a matter of the PATH variable. So try setting it so that your new ld comes before the old one.
Generally, you link with the gcc or g++ program (so it is GCC which matters, not make; read about Invoking GCC and its -fuse-ld=), and that gcc or g++ will run the linker (you might, but I don't recommend to, change its spec file which governs what actual programs are run by gcc or g++ which are only drivers to other programs such as cc1, as, ld, collect2 etc...). To understand what programs gcc or g++ is running, pass it the -v flag.
But "make" still uses the "/usr/bin/x86_64-linux-gnu-ld" (which is 2.24) and still gives the same error.
On my Debian system /usr/bin/x86_64-linux-gnu-ld (it is generally started by gcc, not directly by make) is a symlink. You might (but I don't recommend that) just change that symlink.
BTW, you are using an ancient Ubuntu 14. You'll better upgrade your entire distribution (e.g. to Ubuntu 18.04.1 LTS at end of 2018), because there is not only ld but many other programs which are really old on your system.
Upgrading your distribution will take less time than upgrading, compiling, installing and configuring each individual tool.
Related
I've tried to configure GCC 9.3.0 to produce executable files for DOS. However, for a simple "Hello world!" program in C, it outputs:
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0xd6): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x10b): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x131): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x141): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(crt1.o):crt1.c:(.text+0x3d4): undefined reference to `_environ'
/home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/bin/ld: /home/teo.samarzija/djgpp-9.3.0/lib/gcc/djgpp/9.3.0/../../../../djgpp/lib/libc.a(getenv.o):getenv.c:(.text+0x4): more undefined references to `_environ' follow
collect2: error: ld returned 1 exit status
djgpp-gcc -v outputs:
Using built-in specs.
COLLECT_GCC=djgpp-gcc
COLLECT_LTO_WRAPPER=/home/teo.samarzija/djgpp-9.3.0/libexec/gcc/djgpp/9.3.0/lto-wrapper
Target: djgpp
Configured with: ../gcc-9.3.0/configure --target=djgpp --prefix=/home/teo.samarzija/djgpp-9.3.0 --enable-languages=c,c++,objc,ada,fortran,go
Thread model: single
gcc version 9.3.0 (GCC)
I've also compiled the newest version of the GNU linker and GNU Assembler, they output as their versions:
GNU ld (GNU Binutils) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.
and
GNU assembler (GNU Binutils) 2.34
Copyright (C) 2020 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `djgpp'.
Any idea what I am doing wrong? Have GCC or GAS or GLD stopped supporting DOS some time in the past? I suppose not, because they compile for DOS as a target without warning about that.
I only stumbled on this question because of a more recent Stackoverflow question you asked about some code that didn't run properly in 32-bit Windows 10 inside an NTVDM virtual DOS session.
The problem is that you have not properly built a DJGPP cross compiler and all the needed components. You do not show us what commands you use for the build process and which versions of the dependencies were used and where they came from.
1st thing you need to do is build a DJGPP cross compiler. There are some people who maintain scripts to do just that. One build environment/script in particular I have used successfully is from the user Andrew Wu on Github. It is very simple to use. It appears you are using a Unix type environment based on the output you have shown us. Since you managed to build DJGPP (albeit one that doesn't work) I will assume you have all the necessary build tools installed already. First retrieve the scripts with:
git clone https://github.com/andrewwutw/build-djgpp
Change into the project directory with:
cd build-djgpp
Review the README.md file! It tells you what versions are supported by the script, build requirements for the type of OS you are on etc. At present they support versions all the way to 10.1.0. If you have everything needed choose a version to build (I'll use 9.3.0 since it is the version you are using) and then start the build. You will have to build as root or use sudo as it installs to directory /usr/local/djgpp
./build-djgpp.sh 9.3.0
It will take a while but when finished it should be installed and ready to use. The naming convention is a bit different than prefixing the commands with djgpp-. This script builds things with a more complete target prefix i586-pc-msdosdjgpp-
To add it to your path and set up other environment variables use:
. /usr/local/djgpp/setenv
If you wish it to be done each time you are logged in add that line to your shell login script. For BASH that is in the file ~/.bashrc
Create a file called hello.c containing:
#include<stdio.h>
int main()
{
printf("Hello, world!\n");
}
Compile it to a file called hello.exe:
i586-pc-msdosdjgpp-gcc -O3 -Wall -Wextra hello.c -o hello.exe
Assuming you have a DPMI host installed (like CWSDPMI.EXE), hello.exe should run in MS-DOS, FreeDOS, DOSBox, a Windows NTVDM session etc. When run it should display:
Hello, world!
If you don't wish to build from scratch, Andrew Wu has a number of pre-built packages for a number of the latest DJGPP releases. Platforms they are available for are MacOS, Linux 32, Linux 64, MinGW, and a MinGW standalone version that doesn't need the MinGW environment to run.
I have run in an issue with compiling gdb from source. I am downloading version 8.2.1 but when I try to compile it, I get the following error:
configure: error: *** A compiler with support for C++11 language features is required.
make[1]: *** [configure-gdb] Error 1
My operating system is Red Hat 7.6 (Maipo) but i have a compiled from source gcc(that i set as the default one with an alias in bashrc)
gcc --version
gcc (GCC) 8.2.0
Copyright (C) 2018 Free Software Foundation, Inc.
which gcc
alias gcc='/usr/local/gcc8.2/bin/gcc'
/usr/local/gcc8.2/bin/gcc
which g++
alias g++='/usr/local/gcc8.2/bin/g++'
/usr/local/gcc8.2/bin/g++
What i have tried/read so far
Read the gdb manual regarding the configure and instalation part, also various stackoverflow links but nobody seems to have this problem
Read the README file in the gdb folder/subfolders
Tried setting the following env options CXX_FOR_TARGET=/usr/local/gcc8.2/bin/g++ GCC_FOR_TARGET=/usr/local/gcc8.2/bin/gcc (not sure if i should replace target with my actual target architecture)
Looked in the gdb-8.2.1 folder at the file config.log and found these: ac_cv_env_GCC_FOR_TARGET_value=/usr/local/gcc8.2/bin/gcc
ac_cv_prog_CXX_FOR_TARGET=/usr/local/gcc8.2/bin/g++
ac_cv_prog_GCC_FOR_TARGET=/usr/local/gcc8.2/bin/gcc
However in the C compiler section of the same config log I have found the following:
configure:4284: checking for C compiler version
configure:4293: gcc --version >&5
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-36)
Copyright (C) 2015 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.
I am not sure ifi can use the devtoolset-8 gdb from RedHat because i have compiled gcc with GLIBCXX_USE_CXX11_ABI=1 and on RedHat due to a bug this is disabled by default and i am not sure if gdb will be able to manage the different binary interface.
Short version: What am I doing wrong that is making the GDB configure script not find the correct compiler and how can i fix/workaround this?
Thank you very much for your help!
A C++11-capable compiler for Red Hat Enterprise Linux 7 is provided as part of Red Hat Developer Toolset. It happens to include not just GCC 8, but GDB 8.2 as well, so you may not even have to compile it yourself. The DTS C++ compiler has been built in a special way so that it interoperates with the system C++ runtime. Unless you have replicated those modifications in your GCC build, it will not be compatible with the rest of the system (and you will have to replace the system libstdc++ library).
The system compiler in Red Hat Enterprise Linux 7 is based on GCC 4.8. In that version, C++11 support was still experimental and not enabled by default. You can try to configure GDB with
./configure CXX="g++ -std=gnu+11"
but this is not recommended (only the C++98 mode is supported).
The configure script does not use shell aliases because those are not inherited by shell scripts invoked from a shell. You will have to specify the full path to the C++ compiler explicitly (in the CXX= argument to configure), or adjust the PATH environment variable manually, or use scl enable to do so in a more polished fashion (for software collections such as Developer Toolset).
I just came across this answer GCC Compiler Optimizations, can't link with a main executable file '_' for architecture x86_64 and it made me wonder, is gcc really case sensitive and if yes, what is -on actually? I always used -On to indicate the level of optimization desired. -on does not make any sense to me. However, I tried a little program with -o3 and gcc swallowed it happily. I was unable to find what -on could stand for. In my little test this key has not affected the output in any way, as far as I recognize, while -O3 resulted in smaller executable.
I presumed, that gcc must be case sensitive everywhere - be it Windows or Unix-like OS with case-sensitive FS, at least wrt to command options. And I expected gcc to bail out with error message unrecognized option '-o3' when fed it with -o3, however, it did not.
gcc --version is
gcc (Gentoo 5.4.0-r3 p1.3, pie-0.6.5) 5.4.0
Copyright (C) 2015 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.
arch output:
x86_64
The -o option sets the output file to write to, so compiling with -o3 will cause the compiler to generate an object or executable file called 3
Is there an option to GCC that changes the path of the assembler it uses? I'm getting errors from Solaris /usr/ccs/bin/as when using GCC to attempt to compile Haskell, but I've got a copy of GNU as in my path so when I type which as and as --version they use the GNU version, not the Solaris version. Unfortunately it seems GCC ignores the GNU version in the path and goes to the Solaris version. I'm trying to build Haskell on Solaris and I don't think it sits well with the Solaris assembler. I hope I can change this behaviour with a simple wrapper script so I don't have to recompile GCC.
Specifying the assembler to be used is not possible at run time. It has to be done when configuring gcc:
--with-gnu-as
Specify that the compiler should assume that the assembler it finds is the GNU
assembler. However, this does not modify the rules to find an assembler and will
result in confusion if the assembler found is not actually the GNU assembler.
(Confusion may also result if the compiler finds the GNU assembler but has not
been configured with --with-gnu-as.)
Note the part I've put in italics. Of course you could temporarily change /usr/ccs/bin/as to call the gnu assembler (provided you have the necessary permissions), but the above seems to suggest that you'll very likely run into problems. The gcc build process actually checks the features the assembler supports and generates code for exactly that assembler.
I suggest you build a new version of gcc first (configured to use the gnu tools), and then use that to build ghc.
I have code which produces executables larger than 2GB (it's generated code).
On x64 with gcc 4.3.2 I get errors like:
crtstuff.c:(.text+0x20): relocation truncated to fit:
R_X86_64_32S against `.dtors'
So I understand i need the -mcmodel=large option. However that doesn't do anything or solve the problem on my system.
I am sure I read somewhere, that it was only supported from a particular version of gcc, and the option was ignored on versions before that. I would tell my operations team to install that version of gcc if only I knew what it was. But I just can't find any evidence right now to tell me if that hypothesis is true, and if so in which version the feature was introduced.
For example
(1) Here it is stated that the option doesn't do anything. The book in question claims to cover "GCC 4.x". The book came out 2006.
(2) Here a compiler bug is being reported against the option, therefore I conclude in that version it must do at least something. That seems to be gcc 4.6.1.
So although I can no longer find evidence of exactly in which version the feature was implemented, at least there is evidence that this has changed over time.
I have tried looking through the changelogs for all the various GCC 4.x versions to no avail (and normally they are pretty good so the lack of information there almost implies that I am wrong and nothing has changed between versions.)
Edit: This seems to imply that perhaps it did work, but I need to "recompile crtstuff.c", but I don't really know where I find that file or how I do that.
I believe 4.4 is the version that added support for this feature. I demonstrate below that 4.1 doesn't work while 4.4 does, on something that needs a large data block (rather than code). I'm not sure about 4.2 and 4.3, but both your example and my memory suggest 4.3 didn't have working support for this. My example should let you validate whether a particular installation works or not though, on an otherwise easy to compile bit of code.
As background, I maintain a program that's a fork of the stream benchmark, modified specially to use 64 bit structures for testing larger systems. I was plagued with these "relocation truncated to fit" errors until I started using "-mcmodel=large", and my fork won't compile/run unless that really does work. The oldest version of gcc I've definitely found my program compatible with is the 4.4.5 that ships with Debian Squeeze.
Here's a complete test case showing my fork of stream compiling and using >4GB of RAM with the large model, after failing to do so without the option:
$ gcc --version
gcc (Debian 4.4.5-8) 4.4.5
...
$ git clone https://github.com/gregs1104/stream-scaling.git
$ cd stream-scaling
$ gcc -O3 -DN=200000000 -fopenmp stream.c -o stream
/tmp/cca8rR1I.o: In function `checkSTREAMresults':
stream.c:(.text+0x34): relocation truncated to fit: R_X86_64_32S against `.bss'
...
stream.c:(.text+0x6ab): additional relocation overflows omitted from the output
collect2: ld returned 1 exit status
$ gcc -O3 -DN=200000000 -fopenmp stream.c -o stream -mcmodel=large
$ ./stream
-------------------------------------------------------------
STREAM version $Revision: 5.9 $
-------------------------------------------------------------
This system uses 8 bytes per DOUBLE PRECISION word.
-------------------------------------------------------------
Array size = 200000000, Offset = 0
Total memory required = 4577.6 MB.
...
And here's what happens on a version of gcc that doesn't have the large model, one running RedHat 5 derived software (CentOS 5.8):
$ gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-52)
...
$ gcc -O3 -DN=200000000 -fopenmp stream.c -o stream -mcmodel=large
stream.c:1: sorry, unimplemented: code model ‘large’ not supported yet
So on older versions of gcc, it should throw that error out, not just ignore the option.
crtstuff is a library coming with gcc. The bug report you linked to on the gcc mailing list was from someone trying to build their own gcc for a RedHat 5 system, which as you can see in this last example ships with gcc 4.1. They rebuilt part of gcc with the large model, but it was still linking against the original, 4.1 built crtstuff library. You shouldn't run into that problem if you're using a properly packaged gcc, which is why it wasn't considered a real bug by the gcc developers. I think you just need gcc 4.4 or later.