How to get the folder of the executable?

[Martin Verlaan]

What is the correct way to get the program folder? I mean the folder of the compiled program.

I use GetCurrentDirectory(), which works fine under Linux Mint and Windows. But in Debian, GetCurrentDirectory() points to my source folder and not the compiled folder. Is this a bug or do I use a wrong command?

[Josh]

You mean this?

Code: Select all

GetPathPart (ProgramFilename())

[Martin Verlaan]

You mean this?

Code: Select all

GetPathPart (ProgramFilename())

No, I need a command that returns the folder (path) of the compiled program. And if a user move or copy the folder to a another folder, it should return the path of that new folder.

[Marc56us]

As its name indicates, GetCurrentDirectory() gives the current directory, i.e. the one where you are or the one defined at the start of the parent program or the one (re)defined by SetCurrentDirectory() and not necessarily the one of the generated executable.

Under Linux, it is the one which is displayed if we type the command 'pwd' in shell

Program, path and file:

Code: Select all

Debug ProgramFilename()
Debug GetPathPart( ProgramFilename() )
Debug GetFilePart( ProgramFilename() )

GetPathPart() returns the full path of the program when it is launched, so if this program is moved, of course-on the path also changes and indicates the new path (and not the compilation path)
If that was the question?

[Martin Verlaan]

I am sorry, I read Josh answer to quick and I didn't realized ProgramFileName() is a Purebasic function. It's the correct answer, so thanks to both of you for your quick help

[Martin Verlaan]

It appears that the problem is caused by the import command. I have no idea how to fix it. Whatever I try, the executable points to my source directory instead of the folder that includes the executable. Apparently it is not wise to use subfolders with the import command.

[Little John]

Can you please post some executable code (preferably as short as possible), that demonstrates the issue? For investigating the problem, we first must be able to reproduce it.

[Martin Verlaan]

I tried again to import without using subfolders, but still the same problem. This is what I did:

In Linux, I keep my source code in this folder /var/www/data/purebasic/sourcecode/smartmix versie 1.24
In that folder I have this library file: libbass.so which I import with:

Code: Select all

Import "libbass.so"
; ... some code here ...
EndImport

If can succesfully run this code from the Purebasic Editor.

Then I created an executable and put it in a new folder. In that folder I also copied libbass.so
If I run the program from this folder in Linux Mint, it works fine.

But if I run the same compiled program in Debian (from VirtualBox), I get this error:
Error while loading shared libraries: /var/www/data/purebasic/sourcecode/smartmix versie 1.24/libbass.so: cannot open shared object file: No such file or directory

[ts-soft]

Use allways this:


and the code from josh.

[Martin Verlaan]

I enabled that option but it doesn't help. And import command only accept a literal string, so something like this is not possible:
import GetPathPart(ProgramFilename()) + "folder1\folder2\lib.so"

[ts-soft]

Code: Select all

ImportC "./folder1/folder2/lib.so"

[Martin Verlaan]

This also makes no difference.

Code: Select all

ImportC "./folder1/folder2/lib.so"

[wilbert]

As far as I understand, Linux doesn't search for a .so file in the folder of the executable.
You would either have to place the .so file in one of the standard library folders or add the executable path manually to the places where should be looked for the .so file ( rpath ).
Another option is to use OpenLibrary() / GetFunction() together with PrototypeC instead of importing the functions.

[Martin Verlaan]

As far as I understand, Linux doesn't search for a .so file in the folder of the executable.
You would either have to place the .so file in one of the standard library folders or add the executable path manually to the places where should be looked for the .so file ( rpath ).
Another option is to use OpenLibrary() / GetFunction() together with PrototypeC instead of importing the functions.

Ah! That explains the problem. Although I don't understand why it does work in Mint (maybe because it's more flexible). I'm going to try OpenLibrary(), thanks Wilbert!

[wilbert]

What also might work if you want to use ImportC is to add this extra line to the code.

Code: Select all

ImportC "-Wl,-rpath,'$ORIGIN'" : EndImport

I'm not sure but it might make a difference.