I'm getting some kind of linking error with a program utilizing MS-s waveform API. The code I'm using can be found here: http://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=4422&lngWId=3
It's the first bit of code on the page under the heading "Opening the Sound Device". I'm not getting any errors with the code, however my linker complains quite persistently. The output being the following:
d:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.4.1\..\..\..\crt2.o:crt1.c|| undefined reference to `SetUnhandledExceptionFilter#4'|
d:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.4.1\..\..\..\crt2.o:crt1.c|| undefined reference to `ExitProcess#4'|
d:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.4.1\crtbegin.o:cygming-crtbegin.c|| undefined reference to `GetModuleHandleA#4'|
d:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.4.1\crtbegin.o:cygming-crtbegin.c|| undefined reference to `GetProcAddress#8'|
d:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.4.1\..\..\..\libmingw32.a(pseudo-reloc.o):pseudo-reloc.c|| undefined reference to `VirtualQuery#12'|
d:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.4.1\..\..\..\libmingw32.a(pseudo-reloc.o):pseudo-reloc.c|| undefined reference to `VirtualProtect#16'|
d:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.4.1\..\..\..\libmingw32.a(pseudo-reloc.o):pseudo-reloc.c|| undefined reference to `VirtualProtect#16'|
d:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.4.1\libgcc.a(cygming-shared-data.o)||In function `cmshared_get_ptr_from_atom':|
c:\crossdev\b4.4.1-tdm-1\build-sjlj\mingw32\libgcc\..\..\..\..\gcc-4.4.1\libgcc\..\gcc\config\i386\cygming-shared-data.c|91|undefined reference to `GetAtomNameA#12'|
d:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.4.1\libgcc.a(cygming-shared-data.o)||In function `_cmshared_create_or_grab':|
c:\crossdev\b4.4.1-tdm-1\build-sjlj\mingw32\libgcc\..\..\..\..\gcc-4.4.1\libgcc\..\gcc\config\i386\cygming-shared-data.c|140|undefined reference to `FindAtomA#4'|
d:\codeblocks\mingw\bin\..\lib\gcc\mingw32\4.4.1\libgcc.a(cygming-shared-data.o)||In function `cmshared_add_ptr_as_atom':|
c:\crossdev\b4.4.1-tdm-1\build-sjlj\mingw32\libgcc\..\..\..\..\gcc-4.4.1\libgcc\..\gcc\config\i386\cygming-shared-data.c|118|undefined reference to `AddAtomA#4'|
||=== Build finished: 10 errors, 0 warnings ===|
I can paste the build log here as well if need be. Could anybody let me know what I need to do to fix this? Or even better, how to troubleshoot it myself so I can fix future problems like this myself?
[EDIT]: Okay so I managed to solve this. While playing around in Project->Build Options->Linker Settings->Link Libraries I noticed that if I add something like kernel32.lib I get an error from ld saying "cannot find -lkernel32.lib". So I searched around till I found the libraries I required and I added absolute paths to them, and now my project compiles flawlessly! :D However this was kind of strange since I did add my library search path and it didn't seem to help. So I went over it again to see why it didn't seem to work and it seems like one has to add a trailing backslash to the path name, like if the libraries are located in "C:\SDK\Lib\" one has to add the trailing slash for Code::BLocks to search it correctly. Once that was fixed I changed the option in Linker Settings->Link Libraries to kernel32 as was recommended and now it works without a hitch.
Thanks to everybody who helped me out with this!!! ^_^
I got the same errors when I place a library into system32 and try to link to it with LIBS += L$$quote(C:/Windows/System32).
When I placed it into a normal directory and set the relative path to it, everything works alright.
Looks like you are not linking with Kernel32.lib Check your project properties.
I'd the same problem and after some time I figured out how to do it, the problem relies on the linker, it's trying to link some windows functions into the exe file, and the compiler cannot find those, this is how I solved this:
Install the Windows 7 SDK, you can download it from here: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=3138
Add the library path to the search libraries on CodeBlocks
Project / Build Options (select The project if you want to link it to all the configurations you have) / Search Directories / Linker / Add and place the SDK Library path, which should be at: C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib
Add the references to the windows libraries on the linker settings:
Project / Build Options / Linker Settings / Add (at Link Libraries) and add kernel32, user32 and gdi32 (this last one should be added if you're using windows gui).
That's it... now rebuild your project and it should work flawlessly.
Note: You need to add this settings to the exe project, if you're creating libraries the error will be shown when try to link the exe file.
Related
I am newbee c programmer so be patient. I have a MSP430 C project in Code Composer Studio 7.3 using windows 7. My project (USB) was working fine and then I tried to add more code to incorporate a SPI interface and everything went sideways. I restored my original code but now have problems that weren't there before. Seems to compile but has several unresolved symbols errors in the linker (I think). I have searched/researched many answers to these types of problems on the forum and tried many things (over the past two days!!) and cannot resolve my problem. Possibly I made things worse by copying library/functions directly into my project directory but still didn't seem to change anything. The errors are related to standard MSP430 functions, not my code. My project tree looks like:
project tree
Errors from Console are:
console errors
From everything I have read it indicates that either I have a compiler library path problem or a linker file path problem. Tried a lot of combinations to no avail. Following are the compiler and linker path info:
linker 1
linker 2
If I look in my repository of library stuff downloaded from TI you can see that the dma.h and dma.c files which reference the error message lines in the files are there and I don't understand why the linker can't do its thing.
dma file tree
In the linker under library files I noticed the original libmath.a file didn't point to anything so I found one and added it (not help). Also the libc.a points to a section of 3 directories (different versions of a tool) which each have a different version of libc.a and I think I tried all of them. See below for directories
directories
Any help would be greatly appreciated
A CLUE POSSIBLY: CLUE? In my quest to solve my issues, I created a new CCs project and pasted my main.c file in and then went through a series of compiles solving the errors as the showed up. I was down to one error : can't open source file hal.h. I believe this is a file that was included with the usb example code I started with. After copying it into my project I am back to square on with all the errors listed above. To get here I only needed to point the compiler to driverlib to solve previous errors. The hal.h file seems to only include driverlib.h which is also referenced in my main function so why all the errors??
FIXED BUT WHY!!!
To solve this issue I imported the drivlib directory from the TI repo on my D drive into my project. Now everything compiles. Can anyone tell me why I had to do that given that I had path directives to look on my D drive?? Can it be related to search path length being too long?
I have a Eclipse project using C programming language. I have been stuck with a problem related to linker error since two days now. I have checked various forums to find a solution. Tried a lot of the suggestions but could not resolve it. So as a last resort, i am asking question here. My main program MotorRun.c has code which calls functions in the static library FtMscLib_Static_LIBCMT_Release.Lib which is in Libs folder in the path C:\FT-Project\Common\Libs. I am using MinGW gcc compiler.
When i run the makefile, it generates an error:
c:/mingw/bin/../lib/gcc/x86_64-w64-mingw32/4.9.1/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lC:\FT-Project\Common\Libs\FtMscLib_Static_LIBCMT_Release.Lib
collect2.exe: error: ld returned 1 exit status
The code run by the makefile is
gcc "-LC:\\FT-Project\\Common\\Libs" -shared -o libRoboCopMinGW.exe "src\\MotorRun.o" "-lC:\\FT-Project\\Common\\Libs\\FtMscLib_Static_LIBCMT_Release.Lib"
By looking at the execution code, we can see that the paths and library name has been set correctly, but the linker just cannot find it so that it can link the library with my MotorRun.o object file. Hope someone can help me in finding a solution.
The program MotorRun.c is a very simple one, so i am not posting it here. But if necessary i can update it later. Thanks in advance!
The correct linker syntax is typically something like:
-Lpath_to_library_directory -lname
where the library filename (for a Windows static library) would be name.lib. So your above linker line needs to lose the .lib part. You may also need to prefix the -l argument with another argument -static, to instruct the linker to search for the static library FtMscLib_Static_LIBCMT_Release.Lib otherwise it might try to find the DLL instead.
By the way, there are heaps of posts on StackOverflow regarding the issue of static and dynamic linking with MinGW, so feel free to search for these also. The MinGW web pages also have numerous tips on the same topic.
I was wondering if anyone knew how to link a .so dynamic library (or a .a static library for that mater) in Microsoft visual studio. The following steps have not worked for either .a or .so.
I'm playing around with the vs-android plugging to develop in Android NDK using MVS and I'm trying to add a custom library, compiled as a .so, to the project.
1 - I've created a dynamic library (.so) project alongside one of the sample projects (the san-angeles project), in the same solution.
2 - I've set the .so project, let's call it "engine" as a dependency of san-angeles. The engine.so file is generated without any problems, and appears in the {SolutionFolder?}/Android/Debug folder.
3 - I've added engine.so to the linker additional includes of san-angeles and the {SolutionFolder?}/Android/Debug folder (as a full path, something like C:/projects/.../Debug) to the additional linker directories.
But when I compile san-angeles I get the error:
"arm-linux-androideabi-g++.exe: engine.so: No such file or directory"
So I'm guessing I need to do something else to add a .so/.a to a project? Maybe change the name to libengine.so or something like that? A lot of the default includes have the lib prefix, so I don't know if it's something along those lines.
Thank you for the help,
Jaime
For anybody stumbling on this problem:
Add the directory where the .so resides in Linker -> General -> Additional Library Directories. The project you are compiling must be also a Dynamic Library .so for the linker to be available. This appends the -L flag to the commandline
In the Linker -> Command Line append your .so to the Additional Options with the -l flag with quotes, e.g. -l"MyDynamicLibraryWithoutLibPrefixAndExtension". In my case I wanted to link libassimp.so -> -l"assimp"
Ok, so in my case this was solved by:
1 - Naming the generated engine.a as libengine.a
2 - Instead of, from MVS, adding engine.a to Preferences/Linker/Additional Dependencies, I added to Preferences/Linker/Command Line -l"engine"
With this, the project finally managed to find and engine.a
Hope this helps someone else. :)
I am trying to use GLFW for a school project, and have followed these steps:
1) Download the win32 zip from glfw.org
2) Add /include to my solution's includes
3) Add /lib-msvc100/debug to my solution's libraries
4) Link against glfw.lib and opengl32.lib
5) #include GL/glfw.h
While the project compiles and runs just fine, I can't get around a slew of the following errors:
Warning LNK4099: PDB 'vc100.pdb' was not found with
'glfw.lib(enable.obj)' or at '-projectdir-\Debug\vc100.pdb'; linking object as if no
debug info
One other post here (LNK4099 in GLFW console project with debug configuration) talks about accidently linking both static and dll, but I have not done so. I cannot submit a project with compilation errors :-/
Any idea what's going on here, and how to fix it? Much obliged
You are using the debug version of the GLFW binary, but the vc100.pdb debug information database wasn't included in the zip file. It's a relatively harmless warning and simply means you won't be able to debug normally inside GLFW functions. However, you wouldn't be able to anyway, as the zip file doesn't have the GLFW sources either.
This solved the problem for me:
Open the GLFW project in the solution and go to C++ general options. For all platforms, change the debug build's "debug information format" to "Program Database". Recompile.
UPDATE 1:
My original post was too long and obscured the real problem. I have discovered exactly what is causing the "Multiple targets" bug when Make is called.
UPDATE 2:
I found out that this 'Multiple Targets' bug is caused by GNU Make version 3.8.1 (see here1 and here2). GNU Make 3.8.1 is the current GNU Make released with Cygwin. To summarize the link: The old v3.8.0 handled windows paths fine and the newer v3.8.1 reports errors for windows paths (maybe it's a passive aggressive jab from the FSF?).
When you start a new project in Eclipse+CDT+Cygwin w/o external includes/libraries, everything works fine for me.
As soon as I try to use an external include/library I get the "Multiple targets" bug.
Here is exactly the steps needed to reproduce the bug on Windows+Eclipse+CDT+Cygwin:
Project project properties --> C/C++ Build --> Settings --> Tool Settings --> Cygwin C Compiler --> Includes --> Include Paths (-I) -- > Add Button --> Pick directory --> "C:\dir1\dir2"
I hit build.
It builds with no errors the first time.
I hit build again... I get build errors "Multiple targets. Stop.".
I click on the error.
Eclipse pulls up a makefile. The error happens when make sees the windows path for the new include file from the external library:
# NOTE: Error happens when the first "C:/" occurs
src/main.d src/main.o: ../src/main.c C:/dir1/dir2/ExternalLibrary.h
The reason for Make getting an error "Multiple targets" is because it sees the ":" which is part of the Make syntax for declaring a target. When there are two ":", Make errors out because it doesn't know what to do with "Multiple targets."
I can not edit the makefiles manually because they are immediately regenerated and overwritten [UPDATE: by Eclipse-CDT]. Given that I can't manually edit the makefile.
Is there any way for Eclipse to NOT use the "C:\" path? or tell make to ignore the "C:\" path?
Is this an Eclipse+CDT+Cygwin bug?
If you use Eclipse+CDT+Cygwin... please lend a hand (I don't want to use Visual Studios...)! Maybe I am using Eclipse+CDT+cygwin wrong? How do YOU get External Library includes to work?
*Very very frustrated*
Trying to stay Open-Source and cross-platform user,
Trevor
Turns out the "multiple targets" issue is caused by the current version of GNU Make installed from Cygwin. GNU Make 3.8.1 is the current GNU Make released with Cygwin.
The GNU Make 3.8.1 does not handle windows paths that contain "C:\". So every time your make file has a windows path with "C:\" you get a build error "multiple targets".
The solution I ended up doing is to download a fixed GNU Make v3.8.1. See Here1 or Here2. Then Eclipse+CDT+Cygwin worked fine again.
Update (05-feb-2015):
With an updated cygwin and a new Make (4.0.x) then the problem goes away.
https://superuser.com/questions/154418/where-do-i-get-make-for-cygwin
Had a such a problem, too. Problem was that I included paths on the project settings. Then I had absolute paths. When including the paths in the folder settings with relative paths it worked fine.
I still Got the same problem with eclipse/CDT Juno after update cygwin
to fix it:
you need make 3.80-1 or older and this needs cygintl-2.dll.
download make3.80-1 from
http://www.filewatcher.com/m/make-3.80-1.tar.bz2.286814-0.html
and the needed Dll from
http://www.dllguru.com/cygintl-2.dll.html
extract it somewhere
rename your make in cygwin/bin to makeVersion e.g. make3.82.90
copy cygintl-2.dll and make into cygwin/bin
try build your project in eclipse twice, the problem should be disappeared
gerdi