How do I link SDL .a files with GCC? - gcc

Not a duplicate; Answers on various forums didn't fix the problem.
I am running GCC through commands and I am getting undefined references from SDL even though it appears like I linked SDL correctly, how do I stop from getting those undefined references ?
I do not get undefined references from mingw, just SDL.
This is my command: (all the libraries are being located by GCC from what I can tell)
gcc main.c ^
-o app.exe ^
-I "C:\__coding\tools\SDL2-2.0.10\x86_64-w64-mingw32\include\SDL2" ^
-L "C:\__coding\tools\MinGW\lib\" ^
-l "libmingw32.a" ^
-L "C:\__coding\tools\SDL2-2.0.10\x86_64-w64-mingw32\lib" ^
-l "libSDL2main.a" ^
-l "libSDL2.a"
This is the output:
C:...\main.c:(.text+0xe): undefined reference to 'SDL_Init'
C:...\main.c:(.text+0x13): undefined reference to 'SDL_Quit'
c:/__coding/tools/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: C:\Users\...\AppData\Local\Temp\ccqsLSRk.o: bad reloc address 0x20 in section '.eh_frame'
c:/__coding/tools/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: final link failed: Invalid operation
collect2.exe: error: ld returned 1 exit status
main.c includes SDL.h and just runs SDL_Init() and SDL_Quit().
I also get the classic undefined reference to "winmain" when I remove SDL_Init() and SDL_Quit().
Thanks alot.

Related

Makefile deleted my fortran program

Hi I've never written a makefile before, but I tried my hand at it with my fortran90 final project and the makefile seems to have delete my main program. here's my makefile
# Sample makefile for several modules
#
FC = gfortran
final.x: subs.o func.o maina.o
gfortran -o final.x subs.o func.o maina.o
subs.o: subs.f90
gfortran -c subs.f90
func.o: func.f90
gfortran -c func.f90
maina.o: maina.f90
gfortran -c maina.f90
after running this, my maina.f90 was deleted and the I did not have a copy. this was what it showed when it was running. (The first output is when I ran it and found an error in subs, and after fixing these errors, I got the second output)
$ make
gfortran -o final.x subs.o func.o maina.o
subs.o: In function `__subs_MOD_gauss':
subs.f90:(.text+0x350): undefined reference to `f_'
subs.f90:(.text+0x366): undefined reference to `f_'
subs.o: In function `__subs_MOD_simp':
subs.f90:(.text+0x434): undefined reference to `f_'
subs.f90:(.text+0x4a2): undefined reference to `f_'
subs.f90:(.text+0x51b): undefined reference to `f_'
subs.o:subs.f90:(.text+0x571): more undefined references to `f_' follow
collect2: ld returned 1 exit status
make: *** [final.x] Error 1
$ make
gfortran -c subs.f90
gfortran -o final.x subs.o func.o maina.o
does anyone know why this file deleted my maina.f90, or (though it's probably unlikely) how to get my work back?
EDIT- I should add that I do not have admin or sudo privileges on this computer

Problems with std::stoi, was not declared on MinGW GCC 5.1.0

I tried my code on my computer which is running MinGW GCC 5.1.0.
When I enter :
g++ hope.cpp -o hope -I D:\armadillo-7.600.2\include
The cmd show me:
hope.cpp:183:26: error: 'stoi' was not declared in this scope
Point_Num = stoi(temp[1]);//number of point
^
hope.cpp:190:34: error: 'stof' was not declared in this scope
Point(i, 0) = stof(temp[travel]);
But when I enter:
g++ hope.cpp -o hope -I D:\armadillo-7.600.2\include -std=c++11
The cmd show me:
C:\Users\von77\AppData\Local\Temp\ccXdhQzS.o:hope.cpp:(.text$_ZN4arma7op_norm21vec_norm_1_direct_stdIdEET_RKNS_3MatIS2_EE[_ZN4arma7op_norm21vec_norm_1_direct_stdIdEET_RKNS_3MatIS2_EE]+0x7b): undefined reference to `dasum_'
C:\Users\von77\AppData\Local\Temp\ccXdhQzS.o:hope.cpp:(.text$_ZN4arma7op_norm21vec_norm_2_direct_stdIdEET_RKNS_3MatIS2_EE[_ZN4arma7op_norm21vec_norm_2_direct_stdIdEET_RKNS_3MatIS2_EE]+0x7f): undefined reference to `dnrm2_'
C:\Users\von77\AppData\Local\Temp\ccXdhQzS.o:hope.cpp:(.text$_ZN4arma4blas3dotIdEET_yPKS2_S4_[_ZN4arma4blas3dotIdEET_yPKS2_S4_]+0x3f): undefined reference to `ddot_'
C:\Users\von77\AppData\Local\Temp\ccXdhQzS.o:hope.cpp:(.text$_ZN4arma6lapack5gesddIdEEvPcPiS3_PT_S3_S5_S5_S3_S5_S3_S5_S3_S3_S3_[_ZN4arma6lapack5gesddIdEEvPcPiS3_PT_S3_S5_S5_S3_S5_S3_S5_S3_S3_S3_]+0x8c): undefined reference to `dgesdd_'
collect2.exe: error: ld returned 1 exit status
And after I use atoi instead of stoi:
I got the same result as "g++ hope.cpp -o hope -I D:\armadillo-7.600.2\include -std=c++11".
you need to include the string header
#include <string>
and you need to specify the namespace
std::stoi(temp[1]);

How to statically link a Chicken Scheme program that uses extensions?

I have need to compile and statically link a Chicken program. I expect to use many extensions, most notably http-client.
I can compile the source with the following command:
csc -compile-syntax -static linux-setup.scm
or
csc -R http-client -compile-syntax -static linux-setup.scm
But when I run it, I get the following error:
Error: (require) cannot load extension: http-client
Call history:
##sys#require <--
I have also tried (declare (uses http-client)) in the source, with no success:
linux-setup.o: In function `f_369':
/mnt/data/Documents/Programming/chicken-scheme/linux-setup/linux-setup.c:219:
undefined reference to `C_http_2dclient_toplevel'
collect2: error: ld returned 1 exit status
Error: shell command terminated with non-zero exit status 256: 'gcc' 'linux-setup.o'
-o 'linux-setup' -L"/usr/lib" -Wl,-R"/usr/lib" -static '/usr/lib/libchicken.a' -lm -ldl
Static linking is something I need. This is not an XY problem. I need my executables to run on a freshly-installed Linux system with no dependancies. This is the primary reason I switched from Common Lisp to Scheme in the first place.
What am I doing wrong, please?
Assuming your program is in a-program.scm file:
csc -deploy a-program.scm
cd a-program/
chicken-install -deploy -p $PWD http-client
...et voilà!
edit: turns out that the proper answer to the problem posted is solved in this document: http://www.foldling.org/scheme.html#compiling-statically-linked-chicken-scheme-programs-with-extensions

GHCi linking with cross-calling dynlibs fails on OSX

Setting
Compiler: GHC 7.10.3
I must use two dynamic libraries (libpetsc and libslepc), one of which uses functions from the other. When linking my application, I encounter the following error, which mentions one such symbol (KSPConvergedReasons). NB. my own code does not use this symbol.
user specified .o/.so/.DLL could not be loaded
(dlopen($SLEPC_DIR/arch-darwin-c-debug/lib/libslepc.dylib, 5): Symbol
not found: _KSPConvergedReasons
Referenced from: $SLEPC_DIR/arch-darwin-c-debug/lib/libslepc.dylib
Expected in: flat namespace
in $SLEPC_DIR/arch-darwin-c-debug/lib/libslepc.dylib)
Surely enough, nm -u shows _KSPConvergedReasons as an undefined
symbol (see below).
I don't understand the reason of this behaviour since I first compile
with all the relevant PETSc and SLEPc headers and link against both
.dylibs.
NB:
The symbol in question (KSPConvergedReasons) does exist in the callee library (libpetsc):
$ nm ${PETSC_DIR}/${PETSC_ARCH}/lib/libpetsc.3.7.2.dylib | grep KSPConv
000000000110a652 T _KSPConvergedDefault
0000000001109703 T _KSPConvergedDefaultCreate
000000000110b934 T _KSPConvergedDefaultDestroy
0000000001109a96 T _KSPConvergedDefaultSetUIRNorm
000000000110a074 T _KSPConvergedDefaultSetUMIRNorm
000000000106533d T _KSPConvergedLSQR
0000000001743280 D _KSPConvergedReasons
...
Build + link sequence
Build the C code generated from my own library, which in turn uses headers from the two aforementioned libs:
gcc -c -g -w ${SRCDIR}/Internal/InlineC.c -o ${LIBDIR}/InlineC_c.o -I${PETSC_DIR_ARCH}/include -I${PETSC_DIR}/include -I${SLEPC_DIR_ARCH}/include -I${SLEPC_DIR}/include
Link :
stack exec ghci ${SRCDIR}/Spec.hs ${SRCDIR}/Internal/InlineC.hs ${LIBDIR}/InlineC_c.o -- -isrc/ -L${PETSC_DIR_ARCH}/lib -L${SLEPC_DIR_ARCH}/lib -lpetsc -lmpich -lslepc
Question
Why is this happening and how can I fix this?
Thank you in advance for any pointers,
Marco
Undefined symbols in calling dynlib :
$ nm -u libslepc.3.7.1.dylib | grep KSP
_KSPAppendOptionsPrefix
_KSPConvergedReasons
...

gcc undefined reference to

I'm running..
gcc -c -I/usr/vt/sample ttssample.c
gcc -L. -lttsapi ttssample.o -o ttsample
and I'm getting the following error...
ttssample.o: In function `_TTSFile':
ttssample.c:(.text+0x352): undefined reference to `TTSRequestFile'
ttssample.o: In function `_TTSFileEx':
ttssample.c:(.text+0x5e0): undefined reference to `TTSRequestFileEx'
ttssample.o: In function `_TTSBuffer':
ttssample.c:(.text+0x833): undefined reference to `_TTSRequestBuffer'
ttssample.o: In function `_TTSBufferEx':
ttssample.c:(.text+0xabd): undefined reference to `_TTSRequestBufferEx'
ttssample.o: In function `_TTSBuffering_cont':
ttssample.c:(.text+0xcbf): undefined reference to `_TTSRequestBuffer'
ttssample.o: In function `_TTSBuffering_stop':
ttssample.c:(.text+0xf2d): undefined reference to `_TTSRequestBuffer'
ttssample.o: In function `_TTSBuffering_SSML':
ttssample.c:(.text+0x122b): undefined reference to `_TTSRequestBufferSSMLEx'
ttssample.o: In function `_TTSStatus':
ttssample.c:(.text+0x157b): undefined reference to `TTSRequestStatus'
collect2: ld returned 1 exit status
and TTSRequestFile is in the lib header but it has DllExport on the front of it which I'm wondering is the cause of my error? Any help much appreciated.
DllExport int TTSRequestFile(char *szServer, int nPort, char *pText, int nTextLen, char *szSaveDir, char *szSaveFile, int nSpeakerID, int nVoiceFormat);
Your link command is wrong. Libraries should be specified at the end of the command:
gcc ttssample.o -o ttsample -L. -lttsapi
You could add preprocessor ifdefines around the DllExport call like so:
#ifdef _WIN32
// we are on windows
#elif defined __linux__
//we are on linux
#elif defined __APPLE__&__MACH__
// we are on mac
#endif // os specific
I added for the three platforms I have been compiling cross platform for. Do note that the keywords I use to recognize platforms may change, but the _WIN32 one has been tested with windows 7 and 8.
I found these a year ago on sourceforge I think. I couldn't find the page right now, but I'll get back to you if I find it.
As I cannot yet comment on Nikos C's answer I'll comment it here: Your link command is correct, I can of course not see you files, so I assume your paths are correct. What is important is that -l's need to be in correct order according to dependencies, but this is usually not a problem as far as I have experienced.

Resources