Board index » kylix » How to make Kylix application deployment much easier

How to make Kylix application deployment much easier


2004-07-03 07:33:46 AM
kylix1
Well, if you've read about CrossKylix, then you probably already know
where this is heading to.
In case you prefer to work natively under Linux, read this:
[First some text copied from the updated CrossKylix website]
As you may know, deploying Kylix applications (especially visual CLX
stuff) to another Linux box can be quite some frustrating work.
Please read efg's computer labs excellent report (
www.efg2.com/Lab/Library/Kylix/deployment.htm) for more
information on this.
The biggest problem with deployment is: Unlike on Windows, the system
loader does not load libraries from the program installation directory.
The .so libraries required by Kylix need to be placed in /usr/lib
(or /lib). The only alternative up to now was to create a shell
startup script for your program which would add you programs path to
the LD_LIBRARY_PATH environment variable - ugly. If you don't have
root access to the Linux server (for example if you use shared
hosting), you usually are lost - only the root user may install new
libraries, and most system admins will tell you to take your Kylix app
and go away.
CrossKylix also offers a solution to this: When installing Kylix using
installkylix.exe, a patched copy of Libc.pas (the main linux system unit
for Kylix) is create in c:\crosskylix\libc. Under Linux, the libc
function dlopen does the loading of shared objects (libraries). This
function is declared in Libc.pas. In the patched version (called
ckLibc.pas) this function is extended - if the standard way of loading
a library does not succeed, it will now do a second attempt, using the
path the running application is running in.
What this means is: If your application is using the patched Libc.pas,
you may now simply place all required .so files (usually
libborqt-6.9.0-qt2.3.so + dbexpress drivers etc) into the directory
your application is installed to - and that's it! No more startup shell
scripts, no copying to /usr/lib and running ldconfig etc...
[/end]
The patched Libc.pas is created automaticly with CrossKylix installation.
As I'm of course not allowed to distribute a modified libc.pas, here are
the instructions on how to change Libc.pas to get the same result.
I recommend to either rename Libc.pas to somethingelseLibc.pas, and then
use a Unit Alias "Libc=somethingelseLibc" in your projects, or keep the
Libc.pas name, but copy it to project directory.
The following changes in Libc.pas (located in $kylix/source/rtl/linux)
need to be done:
1. Change "unit Libc.pas" to your new unit name
2. In the implementation section, under " Result := __errno_location; end;"
(line 23415), add this:
function __dlopen(Filename: PChar; Flag: Integer): Pointer; cdecl; external libdlmodulename name 'dlopen';
3. Search and remove the line "function dlopen; external libdlmodulename name 'dlopen';"
4. Before the final "end." of the file, insert this:
function dlopen(Filename: PChar; Flag: Integer): Pointer; cdecl;
var i:integer;
s:string;
begin
writeln('dlopen: '+filename);
result:=__dlopen(Filename, Flag);
// if dlopen fails, the reason might be no path was given to it
// and the required libs are not in the LD_LIBRARY_PATH.
// In this case let's try again, this time giving our application
// directory as path.
if (not assigned(result)) and (Filename[0]<>'/') then
begin
s:=paramstr(0);
// only do this if paramstr(0) contains path info, which should always be the case
if pos('/',s)>0 then
begin
i:=length(Filename);
while (s[i]<>'/') and (i>1) do i:=i-1;
s:=copy(s,1,i);
s:=s+Filename;
// ok, let's try again.
result:=__dlopen(pchar(s), Flag);
end;
end;
end;
That's it. Hope you like this solution, it worked perfectly for me.
Simon
 
 

Re:How to make Kylix application deployment much easier

Oops,
in
function dlopen(Filename: PChar; Flag: Integer): Pointer; cdecl;
this line:
writeln('dlopen: '+filename);
should be removed. It was meant for testing...
Simon
 

Re:How to make Kylix application deployment much easier

Simon Kissel wrote:
Quote
What this means is: If your application is using the patched Libc.pas,
you may now simply place all required .so files (usually
libborqt-6.9.0-qt2.3.so + dbexpress drivers etc) into the directory
your application is installed to - and that's it! No more startup shell
scripts, no copying to /usr/lib and running ldconfig etc...
[/end]
COOL! Thanks- I'll check this out later...
 

{smallsort}

Re:How to make Kylix application deployment much easier

"Simon Kissel" < XXXX@XXXXX.COM >wrote:
Quote
The biggest problem with deployment is: Unlike on Windows, the system
loader does not load libraries from the program installation directory.
The .so libraries required by Kylix need to be placed in /usr/lib
(or /lib). The only alternative up to now was to create a shell
startup script for your program which would add you programs path to=20
the LD_LIBRARY_PATH environment variable - ugly. If you don't have
Huh, what we have here is "in-depth research" on some good, bad and ugly
Quote
CrossKylix also offers a solution to this: When installing 4. Before the final "end." of the file, insert this:

function dlopen(Filename: PChar; Flag: Integer): Pointer; cdecl;
var i:integer;
s:string;
begin
writeln('dlopen: '+filename);
result:=3D__dlopen(Filename, Flag);
// if dlopen fails, the reason might be no path was given to it
// and the required libs are not in the LD_LIBRARY_PATH.
// In this case let's try again, this time giving our application
// directory as path.
if (not assigned(result)) and (Filename[0]<>'/') then
begin
s:=3Dparamstr(0);
// only do this if paramstr(0) contains path info, which should =
always be the case
if pos('/',s)>0 then
begin
i:=3Dlength(Filename);
while (s[i]<>'/') and (i>1) do i:=3Di-1;
s:=3Dcopy(s,1,i);
s:=3Ds+Filename;
// ok, let's try again.
result:=3D__dlopen(pchar(s), Flag);
end;
end;
end;

That's it. Hope you like this solution, it worked perfectly for me.
You've got to be kidding! It can be hardily called a solution.
This code will fail more often then not
 

Re:How to make Kylix application deployment much easier

"Simon Kissel" < XXXX@XXXXX.COM >wrote in message news:< XXXX@XXXXX.COM >...
Quote
The biggest problem with deployment is: Unlike on Windows, the system
loader does not load libraries from the program installation directory.
The .so libraries required by Kylix need to be placed in /usr/lib
(or /lib)....
True!
For those of You wanting to deploy Kylix(3) apps to Debian GNU Linux
(the very best Linux distro), consider to take a look to
debian.erzensoft.com
You can find there the kylix 3 .so stuff packaged as debian packages
and get a trivial way to deploy Kylix apps
Bye
Roberto
--------------------------- snapshot from the site pages ...
Edit the /etc/apt/sources.list and add the line:
* deb debian.erzensoft.com/ stable contrib
Inform apt about the new repository contents running:
* apt-get update
Then install the packages required by your application:
* apt-get install kylix3p-XXX
* apt-get install kylix3p-YYY
* ...
You should be done! Put you Kylix executable somewhere and run it...
... and have fun !
------------------------------------------------------------
 

Re:How to make Kylix application deployment much easier

Hi "Hehe",
Quote
>That's it. Hope you like this solution, it worked perfectly for me.

You've got to be kidding! It can be hardily called a solution.
This code will fail more often then not
Would you like to explain how you came to this conclusion?
I smell trolls.
Simon
 

Re:How to make Kylix application deployment much easier

Simon Kissel wrote:
Quote
Hi "Hehe",

>>That's it. Hope you like this solution, it worked perfectly for me.
>
>You've got to be kidding! It can be hardily called a solution.
>This code will fail more often then not

Would you like to explain how you came to this conclusion?

I smell trolls.
Nope, it's pretty dire coding.
B
 

Re:How to make Kylix application deployment much easier

Quote
Nope, it's pretty dire coding.
Would you like to offer a constructive comment or a code improvement please?
Wayne Sherman
 

Re:How to make Kylix application deployment much easier

Quote
>Would you like to explain how you came to this conclusion?
>
>I smell trolls.

Nope, it's pretty dire coding.
I don't know what you think is dire about it. The linux loader
does pretty much the same - search all registered directories
to see if the library is available there. I've just added
another check for the current directory.
If you are talking about the code itself: Keep in mind that I
did not want the libc.pas interface signature so that this stays
compatible with third-party units without the need to recompile.
That's why I was unable to use extractfilepath etc but had to do
it "by hand".
But feel very welcome to suggest improvements. And feel just as
welcome to just not use the code :)
Simon
 

Re:How to make Kylix application deployment much easier

Simon if you don't know what's wrong with this "deployment solution" then you shouldn't post on the subject. With an attitude like that I don't think you need any help, but just to be a nice guy I'll give you a hint - you need a Linux clue.
Martin
"Simon Kissel" < XXXX@XXXXX.COM >wrote:
Quote
Hi "Hehe",

>>That's it. Hope you like this solution, it worked perfectly for me.
>
>You've got to be kidding! It can be hardily called a solution.
>This code will fail more often then not

Would you like to explain how you came to this conclusion?

I smell trolls.

Simon
 

Re:How to make Kylix application deployment much easier

"Martin" < XXXX@XXXXX.COM >schrieb im Newsbeitrag
Quote
Simon if you don't know what's wrong with this "deployment solution" then
you shouldn't post
on the subject. With an attitude like that I don't think you need any
help, but just to be a nice
guy I'll give you a hint - you need a Linux clue.
Sorry for this posting, but I couldn't help it. You hit a nerve.
Typical answer of some special kind of Linux users: Polite and helpful as
always. Please enlighten us whimps here with the wholy truth - you godfather
of Linux programming! We are afraid that three lines of explanation are not
enough for us low creatures here..
I really can't see the bonus of _not_ loading shared libs in the application
directory. Cluttering the lib directories with all sorts of libraries and
storing the program in different directories and/or writing wrapper shell
scripts ("work-arounds") is better?
There must be something seriously wrong if one could just copy the program
directory to a new machine and the program would be working, right? Better
we copy the source code, provide a nice 50 000 lines (generated) command
line configure script (that doesn't work out of the box) with 100
undocumented command line parameters and let the user figure out how to get
the program configured, compiled and running on his system. Oh, and let us
not forget the nice dependencies to 10 other libraries, that depend on
another ..... Yes, that would be the pure Linux way of doing application
deployment. So we can make sure that only qualified end users are able to
use our programs. (All the rest doesn't deserve the joy of using our
programs, right!?)
And now we pose the question why Linux will never be as attractive to end
users as Windows.
Willi
 

Re:How to make Kylix application deployment much easier

willi krenn wrote:
Quote
There must be something seriously wrong if one could just copy the
program directory to a new machine and the program would be working,
right? Better we copy the source code, provide a nice 50 000 lines
(generated) command line configure script (that doesn't work out of the
box) with 100 undocumented command line parameters and let the user
figure out how to get the program configured, compiled and running on
his system. Oh, and let us not forget the nice dependencies to 10 other
libraries, that depend on another ..... Yes, that would be the pure
Linux way of doing application deployment. So we can make sure that only
qualified end users are able to use our programs. (All the rest doesn't
deserve the joy of using our programs, right!?)
Sounds familar.
Quote
And now we pose the question why Linux will never be as attractive to end
users as Windows.
The reason is that developers must think different under Linux. Linux is
not Windows and so you cannot assume things you have (implicitly) assumed
under Windows. It is simply a fact that Linux does not look for shared
libraries in the application's directory and current directory.
--
Regards,
Andreas Hausladen
(www.kylix-patch.de.vu - unofficial Kylix 3 patches)
 

Re:How to make Kylix application deployment much easier

Andreas Hausladen wrote:
Quote
The reason is that developers must think different under Linux. Linux is
not Windows and so you cannot assume things you have (implicitly) assumed
under Windows. It is simply a fact that Linux does not look for shared
libraries in the application's directory and current directory.
And for a reason too. Even the dot is removed from a users PATH in the newer
distros. Guess why? Security! Just do not follow the hairbrained Windows
scheme of looking for shared objects in the current or the program
directory. Installation is a task for root and should follow the well
established behaviour UNICES follow in this respect.
--
Ruurd
 

Re:How to make Kylix application deployment much easier

Simon Kissel wrote:
Quote
But feel very welcome to suggest improvements. And feel just as
welcome to just not use the code :)
The improvement is to remove the code. For security reasons and for reasons
of avoiding the same nonsense as on Windows called DLL-hell.
--
Ruurd
 

Re:How to make Kylix application deployment much easier

Quote
>But feel very welcome to suggest improvements. And feel just as
>welcome to just not use the code :)

The improvement is to remove the code. For security reasons and for reasons
of avoiding the same nonsense as on Windows called DLL-hell.
Security reasons? Bullshit. What's wrong with having your shared objects inside
your application directory? They are owned by you, and they are run by your
application.
And DLL hell? If you keep your application DLLs in your application directory,
you don't have a DLL hell. Neither on linux nor on Windows. Non-issue.
If you wish to be taken seriously, then NAME your "security reasons". Else I have
no other choice than telling you:
The improvement is to remove YOU. For security reasons and for reasons of
avoiding nonsense...
Simon