My compiler is pooched. I'm trying to compile a simple "Hello World" program in c and I get this error:
ld: warning: directory not found for option '- F/System/Library/Frameworks/'
ld: unknown option: -plugin
collect2: error: ld returned 1 exit status
Googling the error kept giving me links to help for MAC OS. My computer is running Ubuntu 16.04.
This came about from having this error before and implementing its solution or installing clang and removing usr/local/bin/as. Compiler still won't compile butthe error is now the aforementioned.
The program I'm trying to compile:
/* Hello World program */
#include<stdio.h>
int main()
{
printf("Hello World");
}
The uname -m commands brings back x86_64. Running as -version brings back:
GNU assembler (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 later.
This program has absolutely no warranty.
This assembler was configured for a target of `x86_64-linux-gnu'.
For what it was worth I was trying to compile a python program for iOS. Before trying that the compiler worked. What do I need to do to fix the compiler?
Read the error:
ld: warning: directory not found for option '- F/System/Library/Frameworks/' ld: unknown option: -plugin collect2: error:
ld returned 1 exit status ld doesn't know option -plugin.
Take a look at the command that link the objects. And also the directory maybe does not exists.
Related
I am attempting to compile a C program on macOS Catalina. The program will make use of bzip2 decompression. My code includes the line
#include <bzlib.h>
and I am trying to call the function BZ2_bzBuffToBuffDecompress. However, when I run gcc myfile.c -o myfile.c.o, I get the following error:
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1
I am just using a plain text editor and gcc, no IDEs and no CMake files. I suspect I may need a CMake file for this but I am not really sure how to proceed. Any assistance with this is greatly appreciated!
You need to link in the bzip library. gcc myfile.c -o myfile -lbz2. That command assumes the lib is installed into the standard location. Also, you are compiling a final executable so (by strong convention) it should not have a .o suffix.
I started to learn APUE* and compile the source code
Download the source code from Source Code
Extract it to
$ pwd
/Users/me/Desktop/PubRepo/C/APUE/apue.3e
Read readme
$ cat readme
Read the file called DISCLAIMER.
On Freebsd, type "gmake".
On other platforms, type "make" (as long as this is gnu make).
For FAQs, updated source code, and the lost chapter, see http://www.apuebook.com.
Please direct questions, suggestions, and bug reports to sar#apuebook.com.
Steve Rago
January 2013
I checked make version
$ make --version
GNU Make 3.81
Copyright (C) 2006 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.
This program built for i386-apple-darwin11.3.0
make but report error:
gcc -ansi -I../include -Wall -DMACOS -D_DARWIN_C_SOURCE -c -o sleep.o sleep.c
making intro
gcc -ansi -I../include -Wall -DMACOS -D_DARWIN_C_SOURCE getcputc.c -o getcputc -L../lib -lapue
ld: archive has no table of contents file '../lib/libapue.a' for architecture x86_64
clang: error: unable to execute command: Segmentation fault: 11
clang: error: linker command failed due to signal (use -v to see invocation)
make[1]: *** [getcputc] Error 254
make: *** [all] Error 1
I searched and found answer to add cp ./lib/error.c /usr/local/include/
$ cp ./lib/error.c /usr/local/include/
make clean and make
making intro
gcc -ansi -I../include -Wall -DMACOS -D_DARWIN_C_SOURCE getcputc.c -o getcputc -L../lib -lapue
ld: archive has no table of contents file '../lib/libapue.a' for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [getcputc] Error 1
make: *** [all] Error 1
The error is still there.
How could I apply apue.h?
* W Richard Stevens, Stephen A Rago
Advanced Programming in the Unix Environment, 3rd Edn, 2013.
I downloaded the APUE source to a Mac running macOS 10.14.1 Mojave with XCode 10.1 installed (see also Can't compile a C program on a Mac after upgrade to Mojave).
I then ran make CC=/usr/bin/clang (using /usr/bin/gcc is also OK) to use that instead of a home-built GCC 8.2.0, which failed in the db subdirectory. If you don't have any non-standard version of GCC installed on your PATH ahead of /usr/bin/gcc or /usr/bin/clang, you shouldn't need the CC=… argument.
This did a lot of building — all of it successfully (once I'd specified the compiler explicitly; I got an error on the -R. argument with the home-built GCC).
Make sure you have XCode properly installed. Worry about the Command Line Tools — see the "Can't compile" question for information on where to get them. You shouldn't need /usr/include for this, but it is likely to make life easier; again, see the "Can't compiler" question for how to install /usr/include.
There is an answer here from #makhlaghi that helped me a long time ago.
https://unix.stackexchange.com/questions/105483/compiling-code-from-apue.
Here is the answer that worked for me:
A short review of how to write and compile the programs in Advanced Programming in the UNIX® Environment, thanks to slm for helping me understand the steps. You can download the source code from here. I wish this information was included as part of appendix b of the book, where the header file is explained.
The uncompressed file contains directories with the names of the chapters and two others named include and lib. The ones with the names of the chapters have all the programs of that chapter in them.
The include directory contains the header file that is used in most of the programs in the book: apue.h. The lib directory has the source code of the implementations for the that header.
Lets assume the uncompressed file is located at: SCADDRESS/, for example it might be: /home/yourid/Downloads/apue.3e/
Once you uncompress the source code, go in the directory and run make:
$ cd SCADDRESS
$ make
make will compile all the programs in all the chapters. But the important thing is that before that, it will make the library that will contain the implementations of the functions in apue.h.
To compile an example program that you write from the book, run this GCC command (assuming your program's name is myls.c which is the first in the book):
gcc -o myls myls.c -I SCADDRESS/include/ -L SCADDRESS/lib/ -lapue
-I tells gcc which directory to look for the include file. -L tells it the location of the library directory, and -lapue, tells the name of the library file to look for in that directory. Such that -LXXX means to look for a file in the library directory with the name: libXXX.a or libXXX.so.
In a chroot based on CentOS 6.4 I'm working in, linking against ncurses with ld 2.20 succeeds, but linking with ld 2.24 fails. I don't directly invoke the linker, gcc is handling it -- gcc 4.4.7 is using ld 2.20, and gcc 4.8.2 is using ld 2.24.
Here is a minimal example that fails to link with gcc 4.8.2 / ld 2.24 in my particular environment.
#include <ncurses.h>
#include <stdio.h>
#include <stdlib.h>
int main() {
WINDOW* window = NULL;
if (!(window = initscr())) {
printf("Error initializing ncurses.");
exit(1);
}
halfdelay(50);
getch();
endwin();
}
Success (ld 2.20):
$ gcc main.c -lncurses -Wl,--verbose | grep "ncurses.*succeeded"
attempt to open /usr/lib/gcc/x86_64-redhat-linux/4.4.7/../../../../lib64/libncurses.so succeeded
$
Failure (ld 2.24):
$ /opt/gcc/4.8.2/bin/gcc48 main.c -lncurses -Wl,--verbose | grep "ncurses.*succeeded"
attempt to open /usr/lib/../lib64/libncurses.so succeeded
/opt/binutils/2.24/bin/ld24: /tmp/ccCxUFxl.o: undefined reference to symbol 'halfdelay'
/lib64/libtinfo.so.5: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
$
Note that both commands appear to link against the same libncurses.so.
For what it's worth, in a different chroot based on CentOS 5.4, there is a different libncurses version, and it links fine with ld 2.24, but unfortunately, building in that chroot is not an option. The nm utility shows that the (static) libncurses.a here does have the required symbols (nm lists no symbols for libncurses.so -- so I'm just assuming they are similar).
In the CentOS 6.4 chroot, however, nm shows that all of the ncurses symbols I'm getting "undefined reference" messages for are indeed undefined or not present in libncurses.a in the Centos 6.4 chroot, which is confusing, because linking with gcc 4.4.7 works. Something is not right.
Also, I tried producing an object with gcc 4.4.7, and then linking with gcc 4.8.2, but that did not help.
I'm confused as to why the one compiler / linker would succeed while the other would fail. Is this an ABI issue? Does anyone know what is happening here? Are there any flags I can pass to gcc to make the new linker work?
Your libncurses library is itself linked to libtinfo, which causes your older toolchain to also look for symbols in libtinfo.
But newer toolchains normally runs the linker with the --as-needed, and the --no-copy-dt-needed-entries, the latter which probably causes the difference you're seeing.
Basically you'll need to link to libtinfo as well, which is where the halfdelay function resides.
gcc main.c -lncurses -ltinfo
When I try to rpmbuild something I got this error message
checking for x86_64-redhat-linux-gcc... no
checking for gcc... no
checking for x86_64-redhat-linux-cc... no
checking for cc... no
checking for x86_64-redhat-linux-cl.exe... no
checking for cl.exe... no
And I found out that, the tool are in /usr/bin/gcc48 what I did is link the gcc48 to gcc folder: Which I got the idea from this link https://stackoverflow.com/a/13327320/612920
ln /usr/bin/gcc48 /usr/bin/gcc
And when I tried to run rpmbuild again I got this error message:
checking for x86_64-redhat-linux-gcc... no
checking for gcc... gcc
checking whether the C compiler works... no
configure: error: in `/usr/src/rpm/BUILD/courier-unicode-1.1':
configure: error: C compiler cannot create executables
See `config.log' for more details
error: Bad exit status from /var/tmp/rpm-tmp.jrbnrw (%prep)
What is wrong? I had already installed all development tools and its on its latest versions. Can Somebody help me?
And by the way I am using Amazons Redhat (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC))
UPDATED:
config.log
configure:3499: $? = 0
configure:3488: gcc -v >&5
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-amazon-linux/4.8.2/lto-wrapper
Target: x86_64-amazon-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugu$
Thread model: posix
gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC)
configure:3499: $? = 0
configure:3488: gcc -V >&5
gcc: error: unrecognized command line option '-V'
gcc: fatal error: no input files
compilation terminated.
configure:3499: $? = 4
configure:3488: gcc -qversion >&5
gcc: error: unrecognized command line option '-qversion'
gcc: fatal error: no input files
compilation terminated.
configure:3499: $? = 4
configure:3519: checking whether the C compiler works
configure:3541: gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp$
collect2: fatal error: cannot find 'ld'
compilation terminated.
configure:3545: $? = 1
configure:3583: result: no
configure: failed program was:
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3588: error: in `/home/falko/rpm/BUILD/courier-unicode-1.1':
configure:3590: error: C compiler cannot create executables
gcc is one of a number of tools required to build a software package, and as you can see from the error in your config.log, some more are missing from your system:
collect2: fatal error: cannot find 'ld'
It is complaining that it cannot find the system linker (ld).
Before addressing this, I recommend you set the gcc version to be used correctly. Unfortunately the advice you followed from https://stackoverflow.com/a/13327320/612920 is somewhat incomplete.
Redhat based systems provide a mechanism for being able to switch between different implementations of a piece of software at will (for example, different versions). This tool is called alternatives. You should use that to set the GCC version that will be used when you run 'gcc' at the command line. It will update a whole set of symlinks, not just the one you manually set.
sudo alternatives --config gcc
After doing this set the linker to be used:
sudo alternatives --config ld
Note that when I've tried out an AMI linux image, I found that by installing gcc like this:
sudo yum install gcc48
it automatically set the correct 'alternatives' for the newly installed compiler and corresponding linker. I'm not sure how your system got into the state that it is currently in, but if you still have problems after the above procedure, I recommend uninstalling and re-installing gcc and binutils.
After a couple of research I had found out that I am just lacking of ld(GNU linker) tool from RedHat's developer tool set and I also found out that there is an alternative tool just in case ld(GNU linker) is not available, ld.bfd(alternative to the GNU linker) which is in my case it is available. What I did, I make a link from ld.bfd to ld:
ln /usr/bin/ld.bfd /usr/bin/ld
I don't know if it is the proper solution but it works for me.
Reference: Red_Hat_Developer_Toolset
g++ (GCC) 4.7.2
3.7.6-201.fc18.x86_64 #1 SMP Mon Feb 4 15:54:08 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Fedora release 18 (Spherical Cow)
Hello,
I am compiling and having a problem trying to link a program.
The linker error is:
/usr/bin/ld: point.o: undefined reference to symbol '_Znwj##GLIBCXX_3.4'
/usr/bin/ld: note: '_Znwj##GLIBCXX_3.4' is defined in DSO /lib/libstdc++.so.6 so try adding it to the linker command line
/lib/libstdc++.so.6: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
This object file is point.o is trying to call a function that doesn't exist in libstdc++.
When I try and check if the symbol name does exist using readelf I can't find it.
readelf --all libstdc++.so.6.0.17 | grep _Znwj##GLIBCXX_3.4
Is this because the point.o is looking for a symbol in a older libstdc++ that could have been removed in a later version?
Many thanks for any suggestions,
In my case I was using gcc not g++. It used to work in '12, but a later build on a different machine in '14 choked. The gnu compiler has indeed changed. The answer in my case was to add
-lstdc++
onto the end of the linking line, as the error messages suggest. HTH.