Can I make a single executable file from multiple shared objects binary files ?

[gaamaaresosa]

I was looking for similar solution and finaly found this today.
But I have some questions.

I have 1 execuable binary file 30MB
And 5 shared object files as show below.
MyExecutableLinuxBinaryFile
MySharedObject1.so
MySharedObject2.so
MySharedObject3.so
MySharedObject4.so
MySharedObject5.so

I need to make a single self extracted file (NewFile).
When user run that NewFile, it should extract all the above 5 files on a subfolder and run my MyExecutableLinuxBinaryFile file.

Is it possble ?
Can some one help me how to do this ?

My System:
Raspberry Pi -4
Linux 32 bit Buster OS

Thanks in advance

[megastep]

Yes, that's probably something you could do with Makeself as all the files can be in a single archive and they will be unpacked in the same location. You'll have to make sure the dynamic linker is able to find your .so files though.

[gaamaaresosa]

Yes, that's probably something you could do with Makeself as all the files can be in a single archive and they will be unpacked in the same location. You'll have to make sure the dynamic linker is able to find your .so files though.

Thanks for your swift reply.

You'll have to make sure the dynamic linker is able to find your .so files though

I have Imported all the *.so files inside MyExecutableLinuxBinaryFile
And when I run MyExecutableLinuxBinaryFile everything works fine from a folder.

Should we write some script (startup_script [script_args]) ?
How to write it ?
Please help me...

[megastep]

If you just want to run the binary and it is able to load the dynamic libraries from its directory, then your startup script should just be "./MyExecutableBinaryFile" (it's just any command run from inside the directory after extraction)

[gaamaaresosa]

If you just want to run the binary and it is able to load the dynamic libraries from its directory, then your startup script should just be "./MyExecutableBinaryFile" (it's just any command run from inside the directory after extraction)

Is this correct ?
makeself.sh --notemp MyExecutable MyExecutableBinaryFile.run "./MyExecutableBinaryFile" ""

Or should I place any startup_script file inside the MyExecutable folder.
Eg:
Start.sh
./MyExecutableBinaryFile

[megastep]

If you really do need that script to set up the environment prior to starting the binary, then sure, put it in the archive and then use sh start.sh to run it after extraction. Otherwise if the binary can run by itself you can just use it directly.

[gaamaaresosa]

If you really do need that script to set up the environment prior to starting the binary, then sure, put it in the archive and then use sh start.sh to run it after extraction. Otherwise if the binary can run by itself you can just use it directly.

I don't want to set any thing prior to starting the binary.
I need just to start my MyExecutableBinaryFile file.

Can you please correct this line if its wrong ?
makeself.sh --notemp MyExecutable MyExecutableBinaryFile.run "NoTitleNeeded" "./MyExecutableBinaryFile" ""

Note:
Will the above line produce a new file ?

[megastep]

Yeah, it will make a .run file with the contents of your directory. You can run the binary this way and you can also skip the last empty argument if you don't need it.

[gaamaaresosa]

Yeah, it will make a .run file with the contents of your directory. You can run the binary this way and you can also skip the last empty argument if you don't need it.

Thank you so much.
I will try this today !

[gaamaaresosa]

Out of curiosity one more question please:
The *.run file is a zipped file right ?
Any one can extract it and see all the content inside.
Is there any zip passphrase option available to protect the *.run file ?

I mean makeself.sh option should receive a passphrase from command line and store it on the output file.
While running use that hidden passphrase and run.
While extracting ask for passphrase.

Now a days code security is very important, that's why I don't use PyInstaller.

Is this something closer to what I talk ?
--gpg-encrypt : Encrypt the archive using gpg -ac -z $COMPRESS_LEVEL. This will prompt for a password to encrypt with. Assumes that potential users have gpg installed.

[megastep]

Not directly, Makeself archives are basically just compressed tar archives with a stub of shell script to handle the extraction. Yes there are additional options to handle encryption via GPG if that's something you feel like you need.

It is not a substitute for code signatures though, once your files are extracted it's really pretty much the same situation as you still need to be able to load and run the code. I don't think any current Linux kernel has this kind of capability just now.

[gaamaaresosa]

once your files are extracted it's really pretty much the same situation as you still need to be able to load and run the code. I don't think any current Linux kernel has this kind of capability just now.

Yes you are right.
Thanks again !

[gaamaaresosa]

@megastep
A big thanks !
Today I have succeeded making the self extracting archive with your great MakeSelf solutions.
More than everything your proper guidance make me to get the result.

I see the MyExecutableBinaryFile.run file is mere a text file (sh script)
If I open on any text editor I could see the full script.

Is there any solution which should produce a native binary file as a C or C++ binary.
So that it will be like a common executable file.
I know how to make in Windows with even VisualBasic6 (A native exe)
Please refer any solution to make a native binary file.
I know its simple with a stub template exe and appanding the file data on the tail.
But I don't know how to do in linux.

[megastep]

Sorry, I'm not aware of such a solution. A big reason why Makeself exists was to provide a cross-platform way to distribute binaries, since scripts are portable across many Unix operating systems (and even Windows now). So that's the goal of this project, specifically to avoid distributing fully binary installers.

[gaamaaresosa]

Sorry, I'm not aware of such a solution. A big reason why Makeself exists was to provide a cross-platform way to distribute binaries, since scripts are portable across many Unix operating systems (and even Windows now). So that's the goal of this project, specifically to avoid distributing fully binary installers.

Thank you so much again.
I understand the gole of cross plateform execution.
I will proceed as it is.