So I am compiling for MIPS architecture on a Linux 386 host in eclipse CDT. I have a project that is supposed to give me a library I can use on another project.
Compiling of that project works just fine. I end up with a libMyProject file.
So in my second project I reference the library file with the -L option for the path and the -l option for the library. All names are correct, however I end up with a Linker error (file not found).
Thats invoking the linker:
mips-openwrt-linux-g++ -L"/home/user/workspace/MyProject/DebugLibrary" -o "MySecondProject" ./HelloWorld.o -lMyProject
And thats the error I get in eclipse:
/home/user/openwrt/trunk/staging_dir/toolchain-mips_r2_gcc-4.6-linaro_uClibc-0.9.33.2/lib/gcc/mips-openwrt-linux-uclibc/4.6.3/../../../../mips-openwrt-linux-uclibc/bin/ld: cannot find -lMyProject
collect2: ld returned 1 exit status
Any suggestions?
Ok I found it.
Had to append the extension .a to the library in the command line pattern of the linker:
${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT}.a ${INPUTS}
Related
I fail to link the pistache library in Eclipse C++ on my Ubuntu machine. I already make this reference:
Properties > C/C++ Build > Settings > Tool Settings
Under GCC C++ Linker > Libraries > Library search path
Under GCC C++ Compiler > Includes > Include paths
Add /usr/local/include/pistache to each
It throws a bunch of errors like this:
.... undefined reference to `Pistache::Ipv4::any()'
Why does this fail? The autocomplete is able to see the reference when I try rewrite the whole line, but it still errors out.
You have to let the linker use shared libraries and pass the -fpic option to the compiler:
a. First step -shared, see this image
b. Last Step Position Independent Code -fPic, see this image
Update
Another way to solve this is:
a. Add support for pthread to the linker
b.Add pistache to libraries in the linker
I use Eclipse + ARM plugin to build my projects. When I needed to use in my project the StemWin library, I configured my IDE to use external library.
I set
Preferences -> C/C++ General -> Paths and Symbols
I added in "Library Paths" the link to my folder includes library.
I also added the name of my library in tab "Library".
I checked the settings in the compiler tab and I ascertained all should be good.
When I tried to build my project I got an error from linker:
cannot find -lMyLib.a Hello C/C++ Problem
I double checked the name of my library and link, all are correct. This is the output of my linker:
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -L"C:\lib"
-T"C:\arm_toolchain\stm32_workspace\Hello\LinkerScript.ld" -Wl,
-Map=output.map -Wl,--gc-sections -o "Hello.elf" #"objects.list" -lMyLib.a
What should I do from here?
I faced the same problem before.
-l:STemWin526_CM4_GCC.a
-L"C:\Edu_Workspace\STM32F4\stm32f4_bsp_template\Drivers\Middlewares\ST\STemWin\Lib"
Above are my working settings.
With -l:<archive file name> the colon : is important for archive file linking.
And -L will contain library path.
Also for stemwin make sure to compile with hardware floating point
-mfloat-abi=hard -mfpu=fpv4-sp-d16
the convention for the -l option of the linker (say you give -lMyLib.a as a linker option) is to search for a library file with "lib" prepended to the given name and .a (or .so) appended, i.e. your command line searches for a file libMyLib.a.{a,so} which is probably not how it's named.
Either you rename your library according to this convention or give it to the linker command line omitting -l (provided your IDE allows you to do so).
Looks like the problem is in -lMyLib.a which means you're trying to link a static library as a dynamic one.
To link a static lib you have to use its path as with ordinary .o files: ... /path/to/MyLib.a
and the resulting command line should look something like
arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -L"C:\lib" -T"C:\arm_toolchain\stm32_workspace\Hello\LinkerScript.ld" -Wl,-Map=output.map -Wl,--gc-sections -o "Hello.elf" #"objects.list" /path/to/MyLib.a
UPDATE:
Although it might fix the issue, turns out it's not true:
-llibrary
-l library
...
Normally the files found this way are library files—archive files whose members are object files. The linker handles an archive file by scanning through it for members which define symbols that have so far been referenced but not defined. But if the file that is found is an ordinary object file, it is linked in the usual fashion. The only difference between using an -l option and specifying a file name is that -l surrounds library with ‘lib’ and ‘.a’ and searches several directories.
(https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html)
I am running Ubuntu 64bit version, and downloaded the latest 64bit Eclipse.
Installed g++ along with build-essential. Tested g++ to make sure it works from terminal, and it works fine.
alex#ubuntu:~/Desktop$ g++ test.cpp -o test
alex#ubuntu:~/Desktop$ ./test
Hello World!alex#ubuntu:~/Desktop$
However, trying to build simple C++ Hello Word project(one of the default projects that comes with Eclipse), I am getting error.
Description Resource Path Location Type
Program "g++" not found in PATH Preferences, C++/Build/Settings/Discovery, [CDT GCC Builtin Compiler Settings] options C/C++ Scanner Discovery Problem
I have added Environment variable named g++ with value /usr/bin/g++ and the above error went away, however, now I am getting unresolved errors, though project compiles and in the Console shows !!!Hello World!!!
Description Resource Path Location Type
Symbol 'endl' could not be resolved test_hello.cpp /test_hello/src line 13 Semantic Error
Symbol 'cout' could not be resolved test_hello.cpp /test_hello/src line 13 Semantic Error
Symbol 'std' could not be resolved test_hello.cpp /test_hello/src line 10 Semantic Error
Have I correctly entered Environmental variable ?? How can I get fix the "unresolved" error ?? Thanks !
When compiling there are two important things to consider:
1.) Is my path up-to-date with executables?
2.) Is my library path correct?
It appears you satisfy 1.) but not 2.)
The unresolved symbol error means that Eclipse cannot find your library via LD_LIBRARY_PATH or some other medium. It's attempting to locate the standard compiled C++ library.
How did you install g++?
Kindly do this and post the results:
Project > Properties > C/C++ Build > Environment
If everything there appears nominal, you can try
/sbin/ldconfig
which should hopefully re-parse your system library paths and might update your environment.
I am having problems getting NSight Eclipse to link in my libraries:
Building target: SA_V1
Invoking: NVCC Linker
nvcc -L/home/streaming/VidApp_V1.0/src/AudioPreconditioning6Ch/dist/Release/GNU-Linux-x86 -L/home/streaming/cuda-workspace/libConfig/Debug -L/usr/lib32 -link -o "SA_V1" ./V1.1/DeckLinkAPIDispatch.o ./V1.1/DeckLinkAPIDispatch_v7_6.o ./V1.1/audio.o ./V1.1/capture.o ./V1.1/cudaEngine.o ./V1.1/decklink.o ./V1.1/engine.o ./V1.1/filter.o ./V1.1/filterKernel.o ./V1.1/initialize.o ./V1.1/main.o ./V1.1/playback.o ./V1.1/utils.o ./V1.1/videoFuncThread.o ./V1.1/vif.o ./V1.1/vof.o -llibAudioPreconditioning6Ch.so -lliblibConfig.so -llibtiff.so.4.3.2
/usr/bin/ld: cannot find -llibAudioPreconditioning6Ch.so
==> searching for the library I get:
/home/streaming/VidApp_V1.0/src/AudioPreconditioning6Ch/dist/Debug/GNU-Linux-x86/libAudioPreconditioning6Ch.so
/home/streaming/VidApp_V1.0/src/AudioPreconditioning6Ch/dist/Release/GNU-Linux-x86/libAudioPreconditioning6Ch.so
/home/streaming/dist/lib64/libAudioPreconditioning6Ch.so
What am I doing wrong?
Library names in Linux are not the same as in Windows. in VS, i was linking libConfig.lib, so when eclipse asked for the name of the library i typed in: liblibConfig.so which is the name of the file. Uh uh. In Linux the prefix lib is understood as a prefix and the suffix .so is also not part of the name. so entering: libConfig as the library to load (which gets inserted into make as: -llibConfig) solves the problem
I've recently downloaded Xcode 4 and now two of my projects that were working perfectly fine before have started giving me errors. Both errors are effectively to do with linking options, but I can't figure out how to change these options and get rid of the errors.
The first problem is with a project written in C++ using the SDL_ttf and SDL_image frameworks. The project builds correctly, but when I try to run, it gives me the following warnings on the console:
warning: Unable to read symbols for #executable_path/../Frameworks/SDL_ttf.framework/Versions/A/SDL_ttf (file not found).
warning: Unable to read symbols from "SDL_ttf" (not yet mapped into memory).
warning: Unable to read symbols for #executable_path/../Frameworks/SDL_image.framework/Versions/A/SDL_image (file not found).
warning: Unable to read symbols from "SDL_image" (not yet mapped into memory).
Since the files are not being found, the executable cannot load any images making it exit straight away when I try to load images. I think the issue here is that the frameworks are not in the directory above the executable, they are in /Library/Framework/ which worked fine before in Xcode 3.2. How do I resolve this?
The second problem comes when compiling an application I wrote for iOS. Along with giving me a bunch of warnings about depracated code on iOS 5, which I will deal with later, it fails to build due to a linker error which I have no clue how to resolve, it says:
ld: library not found for -lz.1.2.3
Command /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang failed with exit code 1
I can answer the second question.
-lz.1.2.3
should be
-lz
You might have accidentally added the zlib.1.2.3.dylib to the project's "link binary with libraries" build phase. You should use the standard zlib without any version in its filename, or simply add -lz to the Other Linker Flags under Build Settings and not add zlib in the "link binary with libraries" build phase.
As for the missing frameworks my best guess is that it has to do with the relative path, ie if you can get rid of the /../ part and instead provide an absolute path that might resolve the issue.