SFML linking problem

[Lv0f92yv]

I am trying to follow the tutorial on SFML's site and am having an issue when running the executable. I have 'sudo make install'd the lib, and am using the following:

g++ -c main.cpp
g++ -o main main.o -lsfml-system

When running the program, I get:

./main: error while loading shared libraries: libsfml-system.so.1.6: cannot open shared object file: No such file or directory

What do I need to do to point to the lib?

Thanks for any input.

[anonymous23323124]

I am using SFML under windows so it may well be different. However, I assume shared libraries are like DLLs on Windows and I always put the DLLs in the same directory as my executable. So you could try copying the shared libraries there.

EDIT: It is supposed to be possible to point the application to the DLLs with system variables, but that has never worked for me.

[sohguanh]

For Linux or other Unix variants, look at the man pages of where they store the library linker path settings. I think for some it is in a environment variable called $LD_LIBRARY_PATH

On my Linux echo $LD_LIBRARY_PATH show me the paths that the linker command search for those libraries.

Else explicitly list the path during compilation like g++ -L/this/is/my/librarypath -o main main.o -lsfml-system

[Lv0f92yv]

echo $LD_LIBRARY_PATH does not print anything to the screen, but I can do:

g++ -o main main.o -lsfml-system

and then do:

ldd main

which prints:

linux-vdso.so.1 =>  (0x00007fff64939000)
	libsfml-system.so.1.6 => not found
	libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f38bfc6f000)
	libm.so.6 => /lib/libm.so.6 (0x00007f38bf9eb000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f38bf7d4000)
	libc.so.6 => /lib/libc.so.6 (0x00007f38bf451000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f38bffa1000)

The second line there seems to be important - I have tried:

g++ -L/usr/lib -o main main.o -lsfml-system

Which, when ldd'd, gives the same as above in code tags.

What do I search for on the man pages? No results for "library linker settings" or "path" or "linker" etc...

Thanks for the replies.

EDIT: I changed the path specification to -L/lib and it works now. Thanks for the reply.

[Computergeek01]

@ Xander314: That system variable is called PATH: http://support.microsoft.com/kb/310519

@OP: Are you using an IDE? Code::Blocks works with Linux: http://www.codeblocks.org/downloads
Also I'm 90% sure you can find it in that Application data base thing, and it's free.

[anonymous23323124]

I know. I added my SFML DLL path to %PATH% and it still didn't work. I guess I did something wrong...

[Computergeek01]

Drop the DLL into "C:\WINDOWS\system32" then. Which Windows version are you using? This will effect the path of the %SYSTEMROOT% variable the one I gave is for XP.

[Lv0f92yv]

@Computergeek01: I am using Eclipse - my original problem was just from the command line. I am now trying to get it to work with eclipse.

[Lv0f92yv]

Just to update, I have it now working with eclipse. It compiles and runs the example just fine.

Thanks for all the help.

[1yR4jE8b]

Drop the DLL into "C:\WINDOWS\system32" then.

DON'T EVER DO THIS, EVER

[sohguanh]

DON'T EVER DO THIS, EVER

It is most convenient for most developers besides Windows team isn't it ? :P

We have our DLL-hell back in those days. Now with Java, we have our JAR-hell again. For C++, I think we have our .so .a -hell again. This is how libraries are distributed and implemented for different programming languages.

I think for some languages like Python, the solution is simple. In-corporate lot's of libraries into the Python installation and then depending on program calling, load them into memory as and when. But that will mean Python must determine what sorts of libraries are common enough to be incorporated isn't it?

Can anyone propose a revolutionary way of maintaining libraries in a most coherent manner? :P

[Computergeek01]

@ darkestfright: I understand why you would say that, this was just to get them up and running. When\if the OP runs into a DLL conflict I'll be here to show them how to setup a sybolic link (Vista\7+), do compile time linking or (if the respective licenses allow it) simply how to distribute the DLL's in their programs directory. By my estimate the OP's at least a year, maybe two, off from this point so going over relative search paths in the Windows environment won't come up for a pretty long time meanwhile they can enjoy using the lib.

@sohguanh: Then again with solutions like the one in Python, you end up with sub releases so drastically different from eachother that finding tutorials online becomes a game of 'hit or miss' it discourages people like me from bothering to pick it up.