Linux shared object question

[Steel]

Is there a way to make a linux program that uses a .so file look in its local directory (no matter where it is being run) for the .so file in exactly the same way that a windows program will look in its local directory for a .dll?

I have a program where this behaviour is required, the .so cannot be in the libraries folder as there can need to be several different versions of it simultaneously, and it is not possible to place anything in the libraries directories on the machines where it will be run anyway.

Is there any way at all to get linux to cooperate and do what should be the most logical option: do I have my file? No? Perhaps look where I am...

[evilsoup]

Is this a program a bash script you've made , or what? I suspect you would have to get into the source code to do what you want. I think you'd have to replace every instance of "library/filename.so" with "filename.so", but I'm not sure.

[Steel]

Well further looking leads me to believe that this is by design impossible. What a horrible piece of shit.

Luckily, I think it may be possible for my purposes to do this with "export LD_LIBRARY_PATH=." but it is certainly not ideal...

The program is a c++ program. It was originally written for windows and then ported to linux and has worked happily on both OS. I have recently taken some of the program out and put it in a dll on the windows version, and that all works as it should, windows finding the .dll in the local directory and behaving as required. Doing this on linux is turning out to be a massive shit as it seemingly can't look in the directory for the .so.

I'm not sure what you mean by replacing library/filename.so in the source, as it at no point references a .so file directly in the source, the dll/so is included via a header when it is compiled. This works in windows and in linux using the export path above, but I was looking for a way in linux to do it without having to go through the export path step, as this is both tedious and prone to someone else cocking it up when they try to use the program...

[evilsoup]

Sorry, this seems a bit above my head, good luck.

[Steel]

Sorry, this seems a bit above my head, good luck.

Oh well thanks anyway.

The basic reason for using the dll/so is that I have this big program which does "stuff". I want to expose basically a function so that other people can put in whatever they like for that function, but never at any point interact with the vast reams of source code for the rest of it. So by putting this tiny portion in a dll someone else can by whatever method they choose code up whatever form they want the function to take. The function does something really simple in essence, but there are infinitely many ways of getting there (it is in fact the subject of someones entire phd, so if I could compile in all the options then they would be down a thesis...). Then they can make that dll and put it with the program and everything works happily (on windows). On linux you would have to put the .so in the lib folder and could only have one form of the program running at any time, unable to run it once using one function in the dll and simultaneously with another.

So is this a very bad method for doing what I'm doing or is there no other way?

[Steel]

Ok that could work for running it locally.

One of the main reasons for having the program run on linux is so that the program can be used on a cluster. I think there is a way to set the environment when you launch a job, but you aren't able to have to have programs launch other programs during a job.

Hopefully this will all work out in a painless way this morning.

[Hamstray]

is the program precompiled or do you have access to the source with the Makefile?

[Steel]

I wrote everything, so I have full access to the source.

The only constraint is there cant be any system calls or programs launching other programs as that isnt possible on the cluster.

[Hamstray]

how about static linking?

[Steel]

The idea is that with dynamic linking I can give the main bit of the program to someone else compiled as an exe, but then they are able to make changes to this one bit without access to the source for the rest of it.

They can just make a new dll and drop it in and the program works differently.

Unfortunately I cant just achieve this with options in a cfg file that makes the program do different things because figuring out the possible scope for the content of this function is a research phd.

If it was statically linked then there is no way for someone in the future to change the dll for a new one without recompiling the entire program right?

[Hamstray]

possibly load the shared object libraries with libdl

http://www.yolinux.com/TUTORIALS/Librar ... namic.html

section: "Dynamic loading and un-loading of shared libraries using libdl"

[Steel]

possibly load the shared object libraries with libdl

http://www.yolinux.com/TUTORIALS/Librar ... namic.html

section: "Dynamic loading and un-loading of shared libraries using libdl"

Unless I'm missing something don't you still have to specify an absolute path to the library using that method?

This may all be moot as the cluster may not be keen on any kind of dynamic linking, so I'll do it a different way there. The use of dll's is much more practical on windows for the contexts this program is used in, as on linux you can't distribute an executable and you'll have to compile the whole thing from source anyway as compatibility is laughably crap.

[Pu-239]

The idea is that with dynamic linking I can give the main bit of the program to someone else compiled as an exe, but then they are able to make changes to this one bit without access to the source for the rest of it.

They can just make a new dll and drop it in and the program works differently.

Unfortunately I cant just achieve this with options in a cfg file that makes the program do different things because figuring out the possible scope for the content of this function is a research phd.

If it was statically linked then there is no way for someone in the future to change the dll for a new one without recompiling the entire program right?

Iirc it should be possible for the user to statically link a .a file you provide w/ their .a file.