I'm using MinGW with g++ (5.3.0) to compile C and C++ for a while now.
I'm pretty sure I changed nothing but apparently I did because when I compiled my DLLs I noticed I couldn't load them when I used std::string or std::unique_ptr.
Later on I noticed that every single programm I compiled just crashed on startup.
Kinda got around that using -static-libstdc++ as a linker flag, which blew up my file sizes.
Today I fired up my computer and everything went nuts.
SSCCE:
int main() {}
When compiling with g++ sscce.cpp -o sscce.exe it works, but when I do
g++ -c sscce.cpp -o sscce.o
g++ sscce.o -o sscce.exe
I get this:
main.o:main.cpp:(.text+0x280): multiple definition of `_mingw32_init_mainargs'
d:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../crt2.o:(.text+0x280): first defined here
main.o:main.cpp:(.text+0x2c0): multiple definition of `mainCRTStartup'
d:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../crt2.o:(.text+0x2c0): first defined here
main.o:main.cpp:(.text+0x2e0): multiple definition of `WinMainCRTStartup'
d:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../crt2.o:(.text+0x2e0): first defined here
main.o:main.cpp:(.text+0x300): multiple definition of `atexit'
d:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../crt2.o:(.text+0x300): first defined here
main.o:main.cpp:(.text+0x310): multiple definition of `_onexit'
d:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../crt2.o:(.text+0x310): first defined here
main.o:main.cpp:(.text+0x320): multiple definition of `__gcc_register_frame'
d:/mingw/bin/../lib/gcc/mingw32/5.3.0/crtbegin.o:(.text+0x0): first defined here
main.o:main.cpp:(.text+0x410): multiple definition of `__gcc_deregister_frame'
d:/mingw/bin/../lib/gcc/mingw32/5.3.0/crtbegin.o:(.text+0xf0): first defined here
main.o:main.cpp:(.bss+0x4): multiple definition of `_argc'
d:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../crt2.o:(.bss+0x4): first defined here
main.o:main.cpp:(.bss+0x0): multiple definition of `_argv'
d:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../crt2.o:(.bss+0x0): first defined here
main.o:main.cpp:(.eh_fram+0xc8): multiple definition of `__EH_FRAME_BEGIN__'
d:/mingw/bin/../lib/gcc/mingw32/5.3.0/crtbegin.o:(.eh_frame+0x0): first defined here
d:/mingw/bin/../lib/gcc/mingw32/5.3.0/crtbegin.o:(.text+0x92): undefined reference to `_Jv_RegisterClasses'
collect2.exe: error: ld returned 1 exit status
Why does this happen and what can I do to make it stop?
Literally didn't touch anything, not even my PC, and now it works again.
Related
I have this c++ project with classes' definitions inside .hpp files and methods' declarations inside .cpp files.
The project uses a makefile to build and run.
The program ran without errors before but LinkedList didn't work as I wanted so I re-wrote it entirely.
Now LinkedList.hpp includes both the class definition and its methods' declarations.
I adjusted the other classes' methods so that they use LinkedList correctly.
Now when debugging the program I get this multiple definition of, first defined here error.
find: ‘lib’: No such file or directory
g++ -std=c++17 -Wall -Wextra -g -Iinclude -o output/main src/Game.o src/Hero.o src/Title.o src/Level.o src/Menu.o src/Entity.o src/Window.o src/main.o src/Map.o src/Object.o -lncurses
/usr/bin/ld: src/Hero.o:/home/user/projects/project-X-githubClone/projectX/include/Object.hpp:2: multiple definition of `TileTypeStr'; src/Game.o:/home/user/projects/project-X-githubClone/projectX/include/Object.hpp:2: first defined here
/usr/bin/ld: src/Level.o:/home/user/projects/project-X-githubClone/projectX/include/Object.hpp:2: multiple definition of `TileTypeStr'; src/Game.o:/home/user/projects/project-X-githubClone/projectX/include/Object.hpp:2: first defined here
/usr/bin/ld: src/Entity.o:/home/user/projects/project-X-githubClone/projectX/include/Object.hpp:2: multiple definition of `TileTypeStr'; src/Game.o:/home/user/projects/project-X-githubClone/projectX/include/Object.hpp:2: first defined here
/usr/bin/ld: src/Map.o:/home/user/projects/project-X-githubClone/projectX/include/Object.hpp:2: multiple definition of `TileTypeStr'; src/Game.o:/home/user/projects/project-X-githubClone/projectX/include/Object.hpp:2: first defined here
collect2: error: ld returned 1 exit status
make: *** [Makefile:74: main] Error 1
So if I get this correctly, the problem is the multiple definitions of const char* TileTypeStr[].
But why then when I change that array's name to, say, tts the error message still reads "multiple definitions of TileTypeStr"?
and why if I comment out the only 2 references (including its declaration and initialisation) of this array inside the whole project the error message is still the same?
TileTypeStr[] was misplaced after all, moved it inside the toString() method I needed it for, then ran make clean to recompile all of the source files and make to build main.cpp.
By running make and not recompiling the source files I was stuck running the bugged version of the program.
I have a simple proof case file, which is called main.c
void bar(void);
void foo(void)
{
bar();
}
int main(void)
{
return 0;
}
As you can see there is no definition for bar()
My goal is to compile this on windows using cygwin's gcc.
I have figured out that I could use the following linker option:
--unresolved-symbols=ignore-all
This should tell the linker not to care about missing symbols. In the main.c example the missing symbol would not even be an issue, as foo is never called, therefore there should not be an undefined behavior when the program is executed.
I have 2 flavors of gcc, one for embedded ARM targets, and one from cygwin 64bit for windows.
The embedded ARM gcc is from here: https://developer.arm.com/open-source/gnu-toolchain/gnu-rm , version 4_9-2015q3.
The Cygwin gcc is taken from https://cygwin.com 's 64bit installer, version 7.3.0-1
I use these compile options with the compilers:
arm-none-eabi-g++.exe -Wl,--unresolved-symbols=ignore-all main.c
g++.exe -Wl,--unresolved-symbols=ignore-all main.c
The first compiles and links without errors, as for the second I get this error message:
/cygdrive/c/Users/user/AppData/Local/Temp/ccRF8tf5.o:main.c:(.text+0x9): undefined reference to `bar()'
/cygdrive/c/Users/user/AppData/Local/Temp/ccRF8tf5.o:main.c:(.text+0x9): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `bar()'
collect2: error: ld returned 1 exit status
Where clearly the undefined reference to `bar()' message should have been suppressed by the option -Wl,--unresolved-symbols=ignore-all
(The second error message does not appear, if I use gcc from the 32 bit cygwin installer.)
The --help command for the cygwin ld shows the --unresolved-symbols=ignore-all as a valid option.
I suppose the cygwin gcc has been compiled in a way, that this option does not work, even though it is not complaining that it can not validate this option.
If for example I use this command:
g++.exe -Wl,--unresolved-symbols=dummy main.c
I get this error message:
/usr/lib/gcc/x86_64-pc-cygwin/7.3.0/../../../../x86_64-pc-cygwin/bin/ld: bad --unresolved-symbols option: dummy
Which for me tells, that --unresolved-symbols is in fact is an accepted command.
My questions would be:
Is there a way to see which commands are truly accepted by gcc
Is there some other way that could work using cygwin's gcc to compile this main.c example?
Compiling gcc for windows from sources with the proper option could maybe get --unresolved-symbols to work?
My motivation for this whole thing is that I want to unit test a single function from big files, that have multiple functions. Like in the following example:
#include "foobar.h"
int foo(void)
{
return 0;
}
void bar(void)
{
foobar();
}
The declaration of foobar() is in the foobar.h and the definition is in another file called foobar.c
If I wanted to run a unit test, which just links against the symbol foo() I would still get a linker error because of the missing symbol for foobar(). (linking against foobar.o would lead me to link to the complete chain of dependencies, which I want to avoid)
If this --unresolved-symbols option would work, then I would not need to mock or stub the foobar() function in my unit test.
I do understand that there are tools that can create automatically mocks, nevertheless I would like to get this to work.
Thanks for reading through.
I really need your help on this one!
I had a problem with my makefile. The error was very common:
makefile:11: recipe for target 'exec' failed
My makefile looks like this:
CC = g++
PY = python
FLAGS = -std=c++11 -O3
all: main exec data
main: main.cpp
$(CC) $(FLAGS) -o $# $<
exec: main
time ./$<
data: plot.py main
$(PY) $<
As far as im concerned there is no mistake but I still got the error, maybe main.cpp was not compiled?
Anyway I then tried (out of curiosity):
g++ -std=c++11 -O3 -o main.cpp main
And then I got this error:
main: In function `_start':
(.text+0x1360): multiple definition of `_start'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/crt1.o:(.text+0x0): first defined here
main: In function `_fini':
(.fini+0x0): multiple definition of `_fini'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/crti.o:(.fini+0x0): first defined here
main:(.rodata+0x0): multiple definition of `_IO_stdin_used'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/crt1.o:(.rodata.cst4+0x0): first defined here
main: In function `data_start':
(.data+0x0): multiple definition of `__data_start'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/crt1.o:(.data+0x0): first defined here
main:(.rodata+0x8): multiple definition of `__dso_handle'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/crtbegin.o:(.rodata+0x0): first defined here
main: In function `_init':
(.init+0x0): multiple definition of `_init'
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/../../../../lib64/crti.o:(.init+0x0): first defined here
/usr/lib/gcc/x86_64-redhat-linux/6.3.1/crtend.o:(.tm_clone_table+0x0): multiple definition of `__TMC_END__'
main:(.data+0x8): first defined here
/usr/bin/ld: error in main(.eh_frame); no .eh_frame_hdr table will be created.
collect2: error: ld returned 1 exit status
And now my main.cpp is gone. What the actual.. How can I recover it? I have an older version of it because I'm using git, but its rather unfinished and I really need this version.
The error was very common
That's the make error. What did it show before that? Did it run the compiler at all? Was there a compile error? What was it?
I addressed your proximate problem below, but the original issue is the compile error. You're fixating on the fact that a build target failed, rather than on understanding why it failed.
Builds fail all the time: very commonly because there's a mistake in the code, and very rarely because of an error in a previously-working makefile. As a consequence, you usually want to worry about understanding and fixing the compiler error, before you start changing your makefile or running the compiler manually.
And now my main.cpp is gone. What the actual..
Well, in
g++ -std=c++11 -O3 -o main.cpp main
the option -o filename tells g++ to use filename for output. So, it opened main.cpp for output and clobbered the contents.
You meant
g++ -std=c++11 -O3 -o main main.cpp
It's an easy mistake to make, which is why we have build systems to do this stuff for us. And backups. And version control.
In future, you can just type make main to select a single target, and make should tell you what it's doing.
How can I recover it?
From your editor, or version control, or backup, or filesystem-level snapshotting if you have a fancy SAN or, in extremis, from memory.
Nothing teaches good source control and backup habits like having to rewrite something from scratch.
there is no main.cpp file anymore. why exactly is that?
When the build failed, the incomplete output file was deleted.
Consider, for reference, how make works. You have a target called main, so it checks whether a file called main exists.
if main exists, it looks at the dependencies, and sees if any of those files are newer then main
if it thinks main should be (re-)generated (either it doesn't exist or is older than a dependency), it runs the rule you gave it
Now if g++ left an empty (or incomplete) version of main lying around after a failed compilation, how would make know to re-generate it the next time you built?
It's essential that the output file be deleted when compilation fails, because otherwise make wouldn't work correctly. You'd also have a directory full of empty or corrupt partly-compiled executables and object files, which doesn't sound like such a great idea.
In other news, your exec target doesn't create a file called exec. This should be a .PHONY rule. So, probably, should data.
The problem is:
g++ -std=c++11 -O3 -o main.cpp main
Where you specify that the output should be placed in main.cpp. You try to compile main and store the result in main.cpp. Since the compile failed, the output file is removed after compilation stopped. So no main.cpp.
It's simple: Just save the file again in your editor.
To do so, press C-x C-w and type the filename again.
When I try to run the following C++ program: UPDATE (Updated code since the past link had some errors): http://pastie.org/private/pdpfpzg5fk7iegnohebtq
I get the following:
UPDATE
The errors that arise now are as follows:
Any ideas on that?
Thanks.
You're not linking in GradeBook.o so you're getting an undefefined reference.
Try
g++ GradeBookMain.cc GradeBook.cc -o GradeBookMain
You also have a typo "maximun" instead of "maximum" in GradeBook.h
You didn’t tell your compiler where to find the GradeBook constructor definition (hence “undefined reference”). You need to pass all source files separately to the compiler, or create intermediate object files for all compilation units, and link them together.
Effectively, the easiest solution is this:
g++ GradeBookMain.cc GradeBook.cc -o GradeBookMain
To quote one of my favorite IRC bots: Undefined reference is a linker error. It's not a compile error. #includes don't help. You did not define the thing in the error message, you forgot to link the file that defines it, you forgot to link to the library that defines it, or, if it's a static library, you have the wrong order on the linker command line. Check which one.
C++ is case sensitive. So, for instance you can displayMessage, but what you define is DisplayMessage. Those are two distinct functions. You should change the definition of DisplayMessage to displayMessage, or when you call it call DisplayMessage not displayMessage
What your compiler is telling you, is that the GradeBook class is defined and everything is OK at the compiling stage, but when the time comes to link a complete executable program, it can't find the actual code for that class. And this is because you have compiled and linked only GradeBookMain.cc and not GradeBook.cc. You can compile and link them both at the same time like this:
g++ GradeBookMain.cc GradeBook.cc -o program
Or you can compile them separately and then link together:
g++ -c GradeBookMain.cc -o GradeBookMain.o
g++ -c GradeBook.cc -o GradeBook.o
g++ GradeBookMain.o GradeBook.o -o program
You need to also compile in GradeBook.cc.
At the moment the class itself is not being compiled or linked, and as such, the linker cannot find the GradeBook class - causing it to complain.
I'm supposed to use a data analysis program for a physics experiment. I can't get it to compile though.
The code is old, not really compatible with current GCC-versions from what I can find. To make things a bit more time-comsuming, I got the code from a guy who had modified all the makefiles to make it compile on Mac. I have no C++-experience, but with man-pages, Google and patience I have fixed a lot of errors on the way, but I'm stuck on this one, even after a week of tries and googling.
I believe the relevant error message is the following:
/usr/bin/ld: error in /home/daniel/skola/exjobb/miniballscripts
/lib/libCommandLineInterface.so(.eh_frame); no .eh_frame_hdr table will be created.`
What can be the cause, and what can be the remedy?
libCommandLineInterface.so was compiled by me before, without any apparent error messages:
$ make
g++ -g2 -O2 -I./ -c CommandLineInterface.cc -o CommandLineInterface.o
g++ -g -Wl -o /home/daniel/skola/exjobb/miniballscripts/lib/libCommandLineInterface.so
CommandLineInterface.o -lm -L/home/daniel/skola/exjobb/miniballscripts/lib -lgcc -lc
Done
My g++-version is g++ (Ubuntu 4.4.3-4ubuntu5) 4.4.3, amd64.
http://tinypaste.com/9eee9 - make output
http://tinypaste.com/ddbde - GNUmakefile
As I said, I have no experience with C++, so maybe my naive Makefile modifications have destroyed something. My lack of experience also makes me not really knowing what other information is needed to help me, but I'll be glad to reply.
Looks like you have forgotten the -shared command line option when you generate the libCommandLineInterface.so file. That would explain those multiple definition errors. If the linker thinks that the file it is generating is an executable (instead of a dynamic library), then it would link in the startup code, etc. When you try to use this .so file, those symbols coming in from the startup code will clash with those that are being added to the executable that uses the dynamic library.
It is possible that the libTransfer.so errors are related to the same flag being omitted. A shared library is allowed to have dangling references (that get resolved when the library is used), but an executable has to have all the symbols resolved at link time. This is probably an oversimplification of how things are, but I never needed to get into more details on dynamic linking in linux. :) Anyhow, adding -shared option may solve the undefined reference errors as well.
The linking errors of concern start with:
[...]/lib/libCommandLineInterface.so: In function `_start':
(.text+0x0): multiple definition of `_start'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o:(.text+0x0): first defined here
[...]/lib/libCommandLineInterface.so: In function `_fini':
(.fini+0x0): multiple definition of `_fini'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crti.o:(.fini+0x0): first defined here
[...]/lib/libCommandLineInterface.so:(.rodata+0x0): multiple definition of `_IO_stdin_used'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o:(.rodata.cst4+0x0): first defined here
[...]/lib/libCommandLineInterface.so: In function `__data_start':
(.data+0x0): multiple definition of `__data_start'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o:(.data+0x0): first defined here
[...]/lib/libCommandLineInterface.so: In function `__data_start':
(.data+0x8): multiple definition of `__dso_handle'
/usr/lib/gcc/x86_64-linux-gnu/4.4.3/crtbegin.o:(.data+0x0): first defined here
[...]/lib/libCommandLineInterface.so: In function `_edata':
(*ABS*+0x607130): multiple definition of `__bss_start'
[...]/lib/libCommandLineInterface.so: In function `_end':
(*ABS*+0x6073b8): multiple definition of `_end'
[...]/lib/libCommandLineInterface.so: In function `_edata':
(*ABS*+0x607130): multiple definition of `_edata'
[...]/lib/libCommandLineInterface.so: In function `main':
/home/daniel/skola/exjobb/miniballscripts/Common/CommandLineInterface.cc:6: multiple definition of `main'
The symbols that are multiply defined are 'standard' on Unix - and I've never needed to bother with them myself on Mac either, though I don't do GUI programming there.
You need to look at libCommandLineInterface.cc with a very prejudiced attitude and decide whether it provides anything that you need. You might be able to remove it altogether. If it contains some stuff you do need, you will need to cauterize the material that defines _start, and _end and main and so on.
You are also going to have to worry about the missing vtables:
[...]/libTransfer.so: undefined reference to `vtable for Annular'
[...]/libTransfer.so: undefined reference to `ROOT::GenerateInitInstance(Barrel const*)'
[...]/libTransfer.so: undefined reference to `ROOT::GenerateInitInstance(Annular const*)'
[...]/libTransfer.so: undefined reference to `vtable for Barrel'
[...]/libTransfer.so: undefined reference to `vtable for Crystal'
[...]/libTransfer.so: undefined reference to `vtable for Germanium'
It's solved. The eh_frame_hdr-problem was solved by this thread. The undefined references was solved by deleting libTransfer.so after the first make, and then directly afterwards running make again. Don't ask me how, but that made it compile.