So what actually is the problem here?
Between people like me pointing out how silly it is to rely on single vendor solutions and jamesh flying off the handle and calling us "idiots" because we say that, nobody has addressed our OP's (jjames01) problem.
Regardless of IDE there is a command being run here that fails:
Code: Select all
c:/sysgcc/raspberry/bin/../lib/gcc/arm-linux-gnueabihf/6/../../../../arm-linux-gnueabihf/bin/ld.exe: cannot find -l-Wl,--rpath=$ORIGIN
Let's ignore the complexity of the path there but at the end of the day VS is trying to run ld.exe with an option "-l-Wl,--rpath=$ORIGIN"
A quick look at the man page for ld tells us that the "-l" option to ld tells it to link a library.
For example you want to use "libxyz.so" so you would have the option "-l xyz" on your ld command.
What happened to the "lib" part and the ".so" part I hear some ask. Well, that is Unix style born in the depths of history.
Clearly our OP's "-l-Wl,--rpath=$ORIGIN" is telling ld to link the library "-Wl,--rpath=$ORIGIN". Which is of course gibberish and results in ld saying "cannot find...".
I am confident that deep in the bowels of the monster that is VS there are dialogs where one can set paths to libraries and various compiler/linker options.
That "$ORIGIN" bothers me. That is clearly a place holder for an option in VS that has not been set properly. Whatever it is.
To throw out some ideas here:
1) Never use file names with spaces. That will confuse Unix tools no end.
2) Never use uppercase in file names. Or at least be sure you have specified the case correctly. Windows does not care but Unix does.
Memory in C++ is a leaky abstraction .