Hi i am getting several errors while linking my ".s" file together.
First of all, i compile the file via "gcc -S -m32 search.c" to
get my 32-bit assembler code.
Secondly i want to link the program back together by using "gcc -o
search search.s"
If i do this i get the following error: "Error: invalid instruction suffix for `push." I tried to use google to solve the problem and found a solution by using the --32 option flag. But this did not work either. The following error shows up as an result:
usr/bin/ld: i386 architecture of input file is incompatible with i386:x86-64 output. The third option by adding .code32 to the .s file, gcc let me compile it. Though by executing the console immediately says "core dumped".
So i really do not know what to do now. Anyone has an idea how i get things working?
Cheers
Assemble with --32, and link with -m32.
gcc -m32 -o search search.s
Without -m32, the output is going to be a 64-bit executable. The error message is due to the input object being a 32-bit object; you can't produce a 64-bit executable from 32-bit objects.
Related
I'm trying to compile a uvm project on my machine and I keep getting the following error message. I'm on Manajaro, I have multilib enabled on my system and I have followed the instructions on this page All the required dependencies are Installed.
I can start modelsim from commandline without any issues, but when I call this makefile, it always fails at the below line. Which makes me believe I might be missing something related to gcc, but I'm not sure what that is and googling this particular issue has yielded no results.
Compiling /tmp/cyberbemon#cyberbemon-x570aorusmaster_dpi_77438/linux_gcc-5.3.0/exportwrapper.c
# ** Fatal: ** Fatal: (vsim-3828) Could not link 'vsim_auto_compile.so': cmd = '/opt/modeltech/gcc-5.3.0-linux/bin/g++ -shared -fPIC -m32 -o "/tmp/cyberbemon#cyberbemon-x570aorusmaster_dpi_77438/linux_gcc-5.3.0/vsim_auto_compile.so" /home/cyberbemon/Development/uvm/final/tb_build/sub_system_tbs/pss_tb/sim/work/_dpi/auto_compile#/linux_gcc-5.3.0/*.o "/tmp/cyberbemon#cyberbemon-x570aorusmaster_dpi_77438/linux_gcc-5.3.0/exportwrapper.o" -Wl,-Bsymbolic '
# (vsim-50) A call to system(/opt/modeltech/gcc-5.3.0-linux/bin/g++ -shared -fPIC -m32 -o "/tmp/cyberbemon#cyberbemon-x570aorusmaster_dpi_77438/linux_gcc-5.3.0/vsim_auto_compile.so" /home/cyberbemon/Development/uvm/final/tb_build/sub_system_tbs/pss_tb/sim/work/_dpi/auto_compile#/linux_gcc-5.3.0/*.o "/tmp/cyberbemon#cyberbemon-x570aorusmaster_dpi_77438/linux_gcc-5.3.0/exportwrapper.o" -Wl,-Bsymbolic >'/tmp/questatmp.AFzKOV' 2>&1) returned error code '1'.
# The logfile contains the following messages:
# /lib/crti.o: file not recognized: File format not recognized
# collect2: error: ld returned 1 exit status
This issues was caused by Modelsim using a different gcc version, manually deleting all the gcc-..*-linux folders from modelsim directory forced it to use my system GCC and that has solved the issue.
This solution was suggested here
Instead of manually deleting it, you can re-run the installer and choose to remove the GCC components. You will get the same result.
I have installed gcc-plugin in my Ubuntu 16.10-32 bit and the installation have been done correctly:
>$ gcc -print-file-name=plugin
/usr/lib/gcc/i686-linux-gnu/6/plugin
However, when I try to compile the plugin, I get a huge amount of errors, warning, and exceptions ...
I can not understand what is the reason behind this.
Is it a mistake in the compiling command line? or the installation of the gcc-plugin was not the right way?
I have compiled the gcc-plugin file as follow:
gcc -g -I`gcc -print-file-name=plugin`/include -fpic -shared -o my_plugin.so my_plugin.c
any help?
You have to use the C++ compiler g++. The command line looks otherwise ok, but I don't know your source code, of course.
I am attempting to build an application using g++ that is composed of several source files and also uses OpenCV 3.1.0.
The CMD command is:
g++ -o home_surveillance -static -std=c++11 -m64 -IC:\Tools\OpenCV\opencv\build\include -LC:\Tools\OpenCV\opencv\build\x64\vc14\lib -lopencv_world310 configuration_manager.cpp events.cpp image_processor.cpp main.cpp response_module.cpp scheduler.cpp
The error produced is:
C:/Program Files/mingw-w64/x86_64-6.2.0-posix-seh-rt_v5-rev1/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lopencv_world310
collect2.exe: error: ld returned 1 exit status
I have been trying various things and searching for answers for a couple days now. I should note that the application builds properly in Visual Studio 2015. I have tried compiling the source files using g++ with the -c option and they all seem to compile fine. It is just the linking phase that produces an error.
Things I have tried:
Just about every possible combination of the specified command. (Modifying order of the options, -lopencv_world310.a, -lopencv_world310.lib, -lopencv_world310, -l"full_path"+"opencv_world310", etc..)
Checked that all the paths and filenames are correct.
Reinstalled mingw to make sure I was using mingw-w64 since this is a 64-bit application.
Running CMD as admin thinking maybe CMD could not access the path specified with -L option.
Googling and reading every post I could find. (Most posts about "ld.exe cannot find "library_name" are a result of someone using "library_name".a or "library_name".lib as input to the -l option).
Reading mingw documentation on the use of GCC/g++ to ensure I wasn't missing anything obvious.
Praying to Bjarne Stroustrup.
Ritual sacrifice involving a Pentium 2.
and sorry for my not really good english. I'll try my best :)
I am trying to compile a addin for my Casio graphic calculator in C. This works without problems when using the official SDK. Because it is only available for Windows, I want to use gcc.
So I got sh-rtems-gcc and it's binutils from macports and tried to compile my program according to this instructions. I copy-pasted the described addin.ld and crt0.s and placed my main.c and libfxsys.a (from the same guys as the instructions mentioned above) in the same directory. The sub-dir include contains fxsys' headers. I verified the presence of all the functions of the library in the .a file with nm.
When using this command for compilation:
sh-rtems-gcc-4.2.3 -m3 -mb -nostdlib -I./include -c crt0.s main.c
Everything works fine. But then im trying to link:
sh-rtems-gcc-4.2.3 -m3 -mb -nostdlib -L. -o myaddin.elf -Taddin.ld crt0.o main.o -lfxsys
and get the following error:
main.o: In function `__main':
main.c:(.text+0x248): undefined reference to `_Bdisp_AllClr_VRAM'
...
... (--- cut 16 other errors in the same format ---)
...
main.c:(.text+0x360): undefined reference to `_Sleep'
./libfxsys.a(locate.o): In function `_locate':
locate.c:(.text+0x28): undefined reference to `_locate_OS'
collect2: ld gab 1 als Ende-Status zurück
All the missing symbols are in the libfxsys.a. I have verified this with nm.
I have already played with the positions of the library in the command, as this is often mentioned as a source of failure in other posts found in google, but without success. I also tried adding and removing the -lgcc option that is used in the above mentioned instructions, without success.
My Host-Machine is a Intel Mac, OS X 10.6
Because I have no idea how to solve this problem, and get to compile my program, I have to ask: What am I doing wrong? How can I compile my program without using the SDK?
Thanks in advance,
xythobuz
Edit:
I have also tried linking with:
sh-rtems-ld -EB -L. -o myaddin.elf -Taddin.ld crt0.o --start-group main.o libfxsys.a --end-group
But it produces the same output as above.
I can't say the exact problem, but would investigate like this:
Find the library that contains the missing symbols. Use nm to see symbol names
Once you know which library contains the symbols make sure you're linking to it, and in the correct order. Try using recursive symbol resolution options -( -) with your linker.
I have a simple c++ program I am trying to debug, but gdb cannot find the object file for the libraries (or no debug info is available), and it does not seem able to find the debug symbols for my executable either.
I am on OSX 10.5.8, with macports, and I compile my code with
g++-mp-4.5 -Wall -pedantic -std=c++0x -g -ggdb -I/opt/local/include -L/opt/local/lib -lgsl
-static-libstdc++ MCMC-simplex.cpp -o mcmc
(there is only one file, and g++-mp-4.5 is the macports executable for gcc/g++ 4.5 )
When I try running gdb on the resulting executable, I get many error messages (at startup) of the form
warning: Could not find object file "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc45/work/build/i386-apple-darwin9/libgcc/trunctfdf2_s.o" - no debug information available for "../../../gcc-4.5.0/libgcc/../gcc/config/soft-fp/trunctfdf2.c".
which to me indicates that macports has a bug during its build (it seems like gdb is looking for the object files in the temporary build directory).
I should add that when I try to see my programs listing in gdb (the one provided by Apple), it tries to look for a random .s file in /var/tmp, which to me sounds like an assembler file. That is why I say it does not seem able to find the debug symbols for my program either.
When I try MacPorts gdb 7.1, I get
warning: `/var/folders/Xa/XaqHO9PeEC8K-Nrd0L9xWk+++TM/-Tmp-//cc2IvFto.o': can't open to read symbols: No such file or directory.
(no debugging symbols found)...done.
and none of the many error messages that Apple's gdb gives out (although the end result is the same).
Has anyone come across this problem, and came up with a solution?
Unlike other UNIXen, on MacOS the debug info is not linked into the executable. Instead, the executable has a list of object files which were linked into it, and the debugger looks for debug info in these individual object files.
If you remove the object files, then you can't debug.
When you compile and link the executable in "single step", GCC does this:
Create assembly file /tmp/[random-string].s
Assemble it into /tmp/[random-string].o
Link /tmp/[random-string].o with crt0.o, libc, etc. into mcmc executable.
Remove /tmp/[random-string].o and .s
It is that last step which prevents you from debugging.
Solution:
g++-mp-4.5 -Wall -pedantic -std=c++0x -g -ggdb -c MCMC-simplex.cpp
g++-mp-4.5 MCMC-simplex.o -lgsl -static-libstdc++ -o mcmc
This will leave MCMC-simplex.o in the current directory, and will allow GDB to find debug info in it.
Well, another "trick" to keep going with a single compile-and-link step would be to add
-save-temps=obj
to your g++ command line so that
4 Remove /tmp/[random-string].o and .s
is actually sort of not performed (actually you end up having the canonical SOURCE.o and SOURCE.s files in the directory where you're building instead of RANDOM-STRING.[os] in some temp folders, but from the point of view of locating debugging symbols that's fine
It seems to me you had two problems: 1) no debug symbols for executable and 2) no debug symbols for some shared libraries that generated warnings. I was also having problem 2). Employed Russian answered 1) and pointed me in the right direction for 2).
First, if you don't need to debug the libraries mentioned in the warnings, then they can be safely ignored. But of course the warnings are annoying and could hide other problems. In your case and mine, the libraries installed by MacPorts should have had debug symbols stripped, but didn't. The reason that causes a warning is, as Employed Russian says, because the symbols themselves are kept in object files generated during the build process and not in the installed libraries. The libraries store pointers to the object files as part of their (minimal) debug information.
You can verify this with the strings command. If you're gettings warnings that /crazy/path/to/something.o can't be found when loading libsomething.dylib:
strings - libsomething.dylib | grep something.o
Note that you need the '-' (this got me the first time).
To fix it, strip debugging info like so:
strip -S libsomething.dylib
Afterwards, 'dwarfdump --file-stats libsomething.dylib' should show that the "STABS debug" section is empty. (The links to object files are stored in STABS debug format.)
No more ugly warnings.. yay!
That was way too hard.