running kmdr-executor 1.3 separately

Hello.

I'm using PC-BSD and I've got KDE 3.5.9 compiled from ports
(not official 
yet). I've created a PBI with a kommander script (PBI is a
package that 
gathers programs and all the libraries needed by these into
one folder and is 
therefore independent of the system-wide libraries) and
kmdr-executor. The 
problem is that when I try to use the package on another
PC-BSD (with KDE 
3.5.7), Kommander gives an error: "can't load kommander
plugin library 
libkommanderwidgets".

Googling about it turned up that the problem is in some
missing libraries 
(actually .la files). So I've copied over all libkommander*
files, but well, 
it doesn't help. I guess the .la files are just wrong 

How the program is executed:
=====
PATH="/Programs/BaculaBat2.2.8/bin:$PATH"; export
PATH
LD_LIBRARY_PATH="/Programs/BaculaBat2.2.8//autolibs/&qu
ot; ; export LD_LIBRARY_PATH
kmdr-executor bat.kmdr
=====

So as you'd guess, all the libraries are in autolibs/
folder. ldd for 
kmdr-executor after exporting 
LD_LIBRARY_PATH="/Programs/BaculaBat2.2.8//autolibs/&qu
ot;:
=====
kmdr-executor:
        libkommanderwidget.so.0 
=>
/Programs/BaculaBat2.2.8//autolibs//libkommanderwidget.so.0
(0x28090000)
        libkommanderwidgets.so.0 
=>
/Programs/BaculaBat2.2.8//autolibs//libkommanderwidgets.so.0
(0x280f1000)
        libkommanderplugin.so.0 
=>
/Programs/BaculaBat2.2.8//autolibs//libkommanderplugin.so.0
(0x28192000)
        libkio.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libkio.so.6 
(0x281a8000)
        libkdeui.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libkdeui.so.6 
(0x284ca000)
        libkdesu.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libkdesu.so.6 
(0x2877c000)
        libkwalletclient.so.1 
=>
/Programs/BaculaBat2.2.8//autolibs//libkwalletclient.so.1
(0x28795000)
        libkdecore.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libkdecore.so.6 
(0x287a5000)
        libDCOP.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libDCOP.so.6 
(0x289d4000)
        libutil.so.5 =>
/Programs/BaculaBat2.2.8//autolibs//libutil.so.5 
(0x28a05000)
        libart_lgpl_2.so.5 
=> /Programs/BaculaBat2.2.8//autolibs//libart_lgpl_2.so.5
(0x28a11000)
        libidn.so.16 =>
/Programs/BaculaBat2.2.8//autolibs//libidn.so.16 
(0x28a25000)
        libintl.so.8 =>
/Programs/BaculaBat2.2.8//autolibs//libintl.so.8 
(0x28a55000)
        libiconv.so.3 =>
/Programs/BaculaBat2.2.8//autolibs//libiconv.so.3 
(0x28a5e000)
        libkdefx.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libkdefx.so.6 
(0x28b52000)
        libqt-mt.so.3 =>
/Programs/BaculaBat2.2.8//autolibs//libqt-mt.so.3 
(0x28b79000)
        libpng.so.5 =>
/Programs/BaculaBat2.2.8//autolibs//libpng.so.5 
(0x29205000)
        libXext.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libXext.so.6 
(0x29227000)
        libSM.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libSM.so.6 
(0x29234000)
        libICE.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libICE.so.6 
(0x2923b000)
        libXrender.so.1 =>
/Programs/BaculaBat2.2.8//autolibs//libXrender.so.1 
(0x29251000)
        libX11.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libX11.so.6 
(0x2925a000)
        libXau.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libXau.so.6 
(0x2933f000)
        libXdmcp.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libXdmcp.so.6 
(0x29342000)
        librpcsvc.so.3 =>
/Programs/BaculaBat2.2.8//autolibs//librpcsvc.so.3 
(0x29347000)
        libz.so.3 =>
/Programs/BaculaBat2.2.8//autolibs//libz.so.3 
(0x2934f000)
        libfam.so.0 =>
/Programs/BaculaBat2.2.8//autolibs//libfam.so.0 
(0x29360000)
        libjpeg.so.9 =>
/Programs/BaculaBat2.2.8//autolibs//libjpeg.so.9 
(0x29368000)
        libstdc++.so.5 =>
/Programs/BaculaBat2.2.8//autolibs//libstdc++.so.5 
(0x29386000)
        libm.so.4 =>
/Programs/BaculaBat2.2.8//autolibs//libm.so.4 
(0x29451000)
        libpthread.so.2 =>
/Programs/BaculaBat2.2.8//autolibs//libpthread.so.2 
(0x29467000)
        libc.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libc.so.6 
(0x2948c000)
        libaudio.so.2 =>
/Programs/BaculaBat2.2.8//autolibs//libaudio.so.2 
(0x2957c000)
        libXt.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libXt.so.6 
(0x2958f000)
        libmng.so.1 =>
/Programs/BaculaBat2.2.8//autolibs//libmng.so.1 
(0x295da000)
        libXi.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libXi.so.6 
(0x29630000)
        libXrandr.so.2 =>
/Programs/BaculaBat2.2.8//autolibs//libXrandr.so.2 
(0x29638000)
        libXcursor.so.1 =>
/Programs/BaculaBat2.2.8//autolibs//libXcursor.so.1 
(0x2963e000)
        libXinerama.so.1 
=> /Programs/BaculaBat2.2.8//autolibs//libXinerama.so.1
(0x29647000)
        libXft.so.2 =>
/Programs/BaculaBat2.2.8//autolibs//libXft.so.2 
(0x2964a000)
        libfreetype.so.9 
=> /Programs/BaculaBat2.2.8//autolibs//libfreetype.so.9
(0x2965a000)
        libfontconfig.so.1 
=> /Programs/BaculaBat2.2.8//autolibs//libfontconfig.so.1
(0x296c2000)
        liblcms.so.1 =>
/Programs/BaculaBat2.2.8//autolibs//liblcms.so.1 
(0x296ea000)
        libXfixes.so.3 =>
/Programs/BaculaBat2.2.8//autolibs//libXfixes.so.3 
(0x29719000)
        libexpat.so.6 =>
/Programs/BaculaBat2.2.8//autolibs//libexpat.so.6 
(0x2971e000)
=====

So what am I missing? Do I have to create the correct .la
files 
(containing /Programs/BaculaBat2.2.8/autolibs instead of
/usr/local/lib etc) 
with libtool somehow? If so, I guess I'll have to drown
myself into exploring 
libtool..

-- 
Silver
_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

On Thursday 13 March 2008 3:33:49 am Silver Salonen wrote:
> Hello.
>
> I'm using PC-BSD and I've got KDE 3.5.9 compiled from
ports (not official
> yet). I've created a PBI with a kommander script (PBI
is a package that
> gathers programs and all the libraries needed by these
into one folder and
> is therefore independent of the system-wide libraries)
and kmdr-executor.
> The problem is that when I try to use the package on
another PC-BSD (with
> KDE 3.5.7), Kommander gives an error: "can't load
kommander plugin library
> libkommanderwidgets".

Without getting too far into what you're doing (as I'm up
way late fixing some 
cool features for my wife in her wholesale contact manager)
I'm thinking I 
have a fair idea what is going on. For one thing, the error
you're seeing is 
common when mixing version, and you're saying you're coping
la files, etc...

Perhaps the question here is just exactly what you want to
do? Are you making 
BSD packages or just not wanting to do a regular compile?
It' looks like 
you're making things difficult to me, so I'll outline the
guidelines.

Those *.la files are linked libraries. You NEVER mix and
shuffle library files 
because the program will load them as executable code and
look for hooks to 
call functions as defined. The only way you'll ever get away
with this is 
with a program that doesn't have new development and targets
OEM crawling 
stability over features and improvements.

In particular the Kommander executor needs to find it's
correct libraries and 
NOT see any others. This means if you want a dual install
you need to manage 
paths and possibly environment variables. I'm sure it can be
done but it's a 
pain. It's particularly pointless given that 1.3 has had a
raft of bugs fixed 
over 1.22 and since the release I'm only aware of one real
bug, one 
uncomfirmed bug in a plugin and some as yet uncomfirmed
possible issues with 
unsupported uses. 

I'm not sure how to best proceed in your case but I do know
that mixing the 
versions that shipped with 3.5.7 and 3.5.9 is disaster for
both. Plugins are 
incompatible for openers, functions are different and of
course 3.5.7 did not 
make KParts. I don't know if this helps. Install Kommander
seperately 
in /home or replace it in your KDE tree, or work out an
isolated local 
install if you can.

-- 
Eric Laffoon
Project Lead - kdewebdev module
_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

On Thursday 13 March 2008 14:00, Eric Laffoon wrote:
> Without getting too far into what you're doing (as I'm
up way late fixing 
some 
> cool features for my wife in her wholesale contact
manager) I'm thinking I 
> have a fair idea what is going on. For one thing, the
error you're seeing is 
> common when mixing version, and you're saying you're
coping la files, etc...
> 
> Perhaps the question here is just exactly what you want
to do? Are you 
making 
> BSD packages or just not wanting to do a regular
compile? It' looks like 
> you're making things difficult to me, so I'll outline
the guidelines.

PC-BSD's PBI is actually done just by copying all the
binaries and libraries 
into one directory. It's run by setting PATH and
LD_LIBRARY_PATH to this 
directory and running a program from there. All the
libraries are taken with 
ldd (I guess) so there should be all the libraries needed by
binaries in this 
directory.

> Those *.la files are linked libraries. You NEVER mix
and shuffle library 
files 
> because the program will load them as executable code
and look for hooks to 
> call functions as defined. The only way you'll ever get
away with this is 
> with a program that doesn't have new development and
targets OEM crawling 
> stability over features and improvements.

Hmm, I took a look at libkommanderwidgets.la and I see it's
more like a 
configuration file. And it has a line:
=====
dependency_libs=' -R/usr/local/lib -L/usr/local/lib
/usr/local/lib/libkommanderwidget.la
/usr/local/lib/libkio.la /usr/local/lib/libkdesu.la
/usr/local/lib/libkwalletclient.la /usr/local/lib/libfam.la
/usr/local/lib/libkommanderplugin.la
/usr/local/lib/libkdeui.la /usr/local/lib/libkdecore.la
/usr/local/lib/libDCOP.la -lutil
/usr/local/lib/libart_lgpl_2.la /usr/local/lib/libidn.la
/usr/local/lib/libintl.la /usr/local/lib/libiconv.la
/usr/local/lib/libkdefx.la -pthread
/usr/local/lib/libXrender.la -lqt-mt -lpng -lz
/usr/local/lib/libXext.la /usr/local/lib/libX11.la
/usr/local/lib/libXau.la /usr/local/lib/libXdmcp.la -lrpcsvc
/usr/local/lib/libSM.la /usr/local/lib/libICE.la
/usr/local/lib/libjpeg.la'
=====

So as it's not a linked library, it wasn't included in the
package by PBI 
Creator (that actually deals with gathering all the
libraries etc). And I 
guess the dependency_libs= line just includes all the wrong
directories. I 
guess I'd have to somehow create a new .la files that
wouldn't list the 
system-wide folders, but well, I don't know how to do that
or what are 
the .la files actually used for 

> In particular the Kommander executor needs to find it's
correct libraries 
and 
> NOT see any others. This means if you want a dual
install you need to manage 
> paths and possibly environment variables. I'm sure it
can be done but it's a 
> pain. It's particularly pointless given that 1.3 has
had a raft of bugs 
fixed 
> over 1.22 and since the release I'm only aware of one
real bug, one 
> uncomfirmed bug in a plugin and some as yet uncomfirmed
possible issues with 
> unsupported uses. 
> 
> I'm not sure how to best proceed in your case but I do
know that mixing the 
> versions that shipped with 3.5.7 and 3.5.9 is disaster
for both. Plugins are 
> incompatible for openers, functions are different and
of course 3.5.7 did 
not 
> make KParts. I don't know if this helps. Install
Kommander seperately 
> in /home or replace it in your KDE tree, or work out an
isolated local 
> install if you can.

Yep, I don't really want the binary to access system-wide
libraries or 
programs, but only the ones that were gathered for its use.
It's actually 
achieved by setting PATH to its directory
/Programs/BaculaBat2.2.8/bin, 
right? So if I'd include all the KDE binaries it needs in
there, it would 
suffice, wouldn't it?

But I still wonder how can I know in which point the
"mixing different 
versions" begins 

-- 
Silver
_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

On Thursday 13 March 2008 5:37:56 am Silver Salonen wrote:
> On Thursday 13 March 2008 14:00, Eric Laffoon wrote:
> > Without getting too far into what you're doing (as
I'm up way late fixing
>
> some
>
> > cool features for my wife in her wholesale contact
manager) I'm thinking
> > I have a fair idea what is going on. For one
thing, the error you're
> > seeing is common when mixing version, and you're
saying you're coping la
> > files, etc...
> >
> > Perhaps the question here is just exactly what you
want to do? Are you
>
> making
>
> > BSD packages or just not wanting to do a regular
compile? It' looks like
> > you're making things difficult to me, so I'll
outline the guidelines.
>
> PC-BSD's PBI is actually done just by copying all the
binaries and
> libraries into one directory. It's run by setting PATH
and LD_LIBRARY_PATH
> to this directory and running a program from there. All
the libraries are
> taken with ldd (I guess) so there should be all the
libraries needed by
> binaries in this directory.

Hmmm? I guess this is why BSD often gets attention for KDE
fixes. In theory it 
should be as simple, but rarely is. There are too many ways
to do things and 
often there are extra configurations going on in KDE.
Actually I run Gentoo, 
which is similar to BSD in using a ports style build. 
>
> > Those *.la files are linked libraries. You NEVER
mix and shuffle library
>
> files
>
> > because the program will load them as executable
code and look for hooks
> > to call functions as defined. The only way you'll
ever get away with this
> > is with a program that doesn't have new
development and targets OEM
> > crawling stability over features and
improvements.
>
> Hmm, I took a look at libkommanderwidgets.la and I see
it's more like a
> configuration file. And it has a line:
> =====
> dependency_libs=' -R/usr/local/lib -L/usr/local/lib
> /usr/local/lib/libkommanderwidget.la
/usr/local/lib/libkio.la
> /usr/local/lib/libkdesu.la
/usr/local/lib/libkwalletclient.la
> /usr/local/lib/libfam.la
/usr/local/lib/libkommanderplugin.la
> /usr/local/lib/libkdeui.la
/usr/local/lib/libkdecore.la
> /usr/local/lib/libDCOP.la -lutil
/usr/local/lib/libart_lgpl_2.la
> /usr/local/lib/libidn.la /usr/local/lib/libintl.la
> /usr/local/lib/libiconv.la /usr/local/lib/libkdefx.la
-pthread
> /usr/local/lib/libXrender.la -lqt-mt -lpng -lz
/usr/local/lib/libXext.la
> /usr/local/lib/libX11.la /usr/local/lib/libXau.la
> /usr/local/lib/libXdmcp.la -lrpcsvc
/usr/local/lib/libSM.la
> /usr/local/lib/libICE.la /usr/local/lib/libjpeg.la'
=====
>
> So as it's not a linked library, it wasn't included in
the package by PBI
> Creator (that actually deals with gathering all the
libraries etc). And I
> guess the dependency_libs= line just includes all the
wrong directories. I
> guess I'd have to somehow create a new .la files that
wouldn't list the
> system-wide folders, but well, I don't know how to do
that or what are
> the .la files actually used for 

Between being really really tired (I just finished a UI
makeover for a 
MainWindow running database forms in the frame... it saves
state for numerous 
settings on the main form and manages duplication and popup
synchronization 
with a custom toolbar that only shows with the main form -
it's got dropdown 
combos) and that I haven't looked for a while. I was going
by what I remember 
being told as to *.la and *.so files as to one being static
and one being 
dynamic. It seems the *.la file maps the *.so file. I use
the *.la file to 
load KParts. In any case it's not a place I generally need
to look.  What I 
said goes though, you can't mix *.la or *.so files between
versions.
>
> > In particular the Kommander executor needs to find
it's correct libraries
>
> and
>
> > NOT see any others. This means if you want a dual
install you need to
> > manage paths and possibly environment variables.
I'm sure it can be done
> > but it's a pain. It's particularly pointless given
that 1.3 has had a
> > raft of bugs
>
> fixed
>
> > over 1.22 and since the release I'm only aware of
one real bug, one
> > uncomfirmed bug in a plugin and some as yet
uncomfirmed possible issues
> > with unsupported uses.
> >
> > I'm not sure how to best proceed in your case but
I do know that mixing
> > the versions that shipped with 3.5.7 and 3.5.9 is
disaster for both.
> > Plugins are incompatible for openers, functions
are different and of
> > course 3.5.7 did
>
> not
>
> > make KParts. I don't know if this helps. Install
Kommander seperately
> > in /home or replace it in your KDE tree, or work
out an isolated local
> > install if you can.
>
> Yep, I don't really want the binary to access
system-wide libraries or
> programs, but only the ones that were gathered for its
use. It's actually
> achieved by setting PATH to its directory
/Programs/BaculaBat2.2.8/bin,
> right? So if I'd include all the KDE binaries it needs
in there, it would
> suffice, wouldn't it?
>
> But I still wonder how can I know in which point the
"mixing different
> versions" begins 

There are actually multiple build paths in the
configuration. Effectively 
you're looking to your main build for KDE libraries and
setting your isolated 
install separately. In theory you should be okay, but if not
configured 
correctly you could end up without icons or calling the
wrong library. In 
fact I'm not even sure some of the internals in Kommander
don't create 
problems here. I can't recall for sure, at least not without
some sleep.

If you don't have a really extremely good reason not to
uninstall the old 
version I'd consider removing it. Not only are there an
amazing amount of new 
features there but it retains 100% compatibility with 1.2x
versions and in 
fact will run everything going back to the beta with minor
editing.

-- 
Eric Laffoon
Project Lead - kdewebdev module
_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

On Thursday 13 March 2008, Silver Salonen wrote:
> Kommander gives an error: "can't load kommander
plugin library
> libkommanderwidgets".

The executor binary (kmdr-executor) will not run if the
above library is 
not found.  libkommanderwidgets is a plugin loaded by the
KDE plugin 
loaded method, and they search for it in the KDE library
paths, by 
default that is $KDEDIRS/lib (for all values from $KDEDIRS,
or for 
$KDEDIR if that is specified, or from $PATH_TO_KDE/lib if
none is 
specified). To make it more interesting, lib can be lib64
(or even 
something else), depending how KDE was configured prior to
compiling, but what I wrote above is the default.
 I'm not sure if they are looked in $LD_LIBRARY_PATH, 
probably they aren't.
 Speaking of .la files, they are libtool archives, giving
information 
about shared libraries and their dependencies. You should
never need
to modify them, they are created correctly at build time. 

 So as you can see, what you need for the kmdr-executor is:
- a KDE installation (kdelibs is enough)
- all KDE library dependencies
- the Kommander libraries
- the kmdr-executor
- all installed in the same path (this is not a hard
requirement, but 
a good thing to do, otherwise you have to play with
environment 
variables)

Andras
 
-- 
 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org


_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

Hi!

Thank you for the information, that was what I was looking
for 

But some more explanations and questions will follow ;)

The idea of the PBI is that it's possible to use
Kommander-based script in any 
environment, not only the one it was built in. I.e. I have
KDE 3.5.9, but 
when some other user installes the PBI, he should be able to
use the program 
as well (even if he doesn't have Kommander installed at all
or has a very 
minimal KDE installation). Hence the need for all
incompatible libraries to 
be included in the package. It's a sort of chroot for the
program, but 
achieved by setting suitable path-variables.

On Friday 14 March 2008 09:31, Andras Mantia wrote:
> On Thursday 13 March 2008, Silver Salonen wrote:
> > Kommander gives an error: "can't load
kommander plugin library
> > libkommanderwidgets".
> 
> The executor binary (kmdr-executor) will not run if the
above library is 
> not found.  libkommanderwidgets is a plugin loaded by
the KDE plugin 
> loaded method, and they search for it in the KDE
library paths, by 
> default that is $KDEDIRS/lib (for all values from
$KDEDIRS, or for 
> $KDEDIR if that is specified, or from $PATH_TO_KDE/lib
if none is 
> specified). To make it more interesting, lib can be
lib64 (or even 
> something else), depending how KDE was configured prior
to
> compiling, but what I wrote above is the default.
>  I'm not sure if they are looked in $LD_LIBRARY_PATH, 
> probably they aren't.

Is it possible to include kdelibs from one path, and
libkommanderwidgets from 
another? Or tell kdelibs that it should search for
libkommanderwidgets some 
other place? May setting
KDEDIRS="/MyProgram/libs:$KDEDIRS" suffice?

>  Speaking of .la files, they are libtool archives,
giving information 
> about shared libraries and their dependencies. You
should never need
> to modify them, they are created correctly at build
time. 

If they have information about where to include libraries
from, I guess that's 
where I can tweak where to include Kommander-specific stuff
and all the other 
libraries needed?

>  So as you can see, what you need for the kmdr-executor
is:
> - a KDE installation (kdelibs is enough)
> - all KDE library dependencies
> - the Kommander libraries
> - the kmdr-executor
> - all installed in the same path (this is not a hard
requirement, but 
> a good thing to do, otherwise you have to play with
environment 
> variables)
> 
> Andras

So, which libraries are really incompatible? Can any version
of kdelibs (and 
its dependencies) be used?

-- 
Silver
_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

Hi,

On Friday 14 March 2008, Silver Salonen wrote:
> I
> have KDE 3.5.9, but when some other user installes the
PBI, he should
> be able to use the program as well (even if he doesn't
have Kommander
> installed at all or has a very minimal KDE
installation). Hence the
> need for all incompatible libraries to be included in
the package.
> It's a sort of chroot for the program, but achieved by
setting
> suitable path-variables.

I see, but this will be challenging, as KDE libraries are
not that small 
and might depend on other libs. But if you know the klick
project 
(http://klik.atekon.de/),
they do something similar.

> Is it possible to include kdelibs from one path, and
> libkommanderwidgets from another? Or tell kdelibs that
it should
> search for libkommanderwidgets some other place? May
setting
> KDEDIRS="/MyProgram/libs:$KDEDIRS" suffice?

Yes, you can do something like that. With the notice, that
you don't nee
d to add "libs" to the path.
E.g your KDE is in /opt/kde3 and KDEDIRS=/opt/kde3 by
default.
You install Kommander in /opt/kommander, than you need:
KDEDIRS=/opt/kommander:$KDEDIRS
prior to run kmdr-executor. But this is valid only for
plugin libs,
for "real" libraries, you need to change
LD_LIBRARY_PATH
as well:
LD_LIRBARY_PATH=/opt/kommander/lib:$LD_LIBRARY_PATH

> >  Speaking of .la files, they are libtool archives,
giving
> > information about shared libraries and their
dependencies. You
> > should never need to modify them, they are created
correctly at
> > build time.
>
> If they have information about where to include
libraries from, I
> guess that's where I can tweak where to include
Kommander-specific
> stuff and all the other libraries needed?

I doubt modifying .la files is a good idea. Try first with
changing only 
the environment variables (KDEDIRS, LD_LIBRARY_PATH, PATH).

The problem is if you install your PBI onto a computer that
has an older 
KDE, it can easily break. So you have to decide what KDE to
support.
E.g you want to support KDE 3.5.x (x is from 0 to 9). In
that case you
need to build Kommander against KDE 3.5.0 when you create
your
PBI. 

> So, which libraries are really incompatible? Can any
version of
> kdelibs (and its dependencies) be used?

See above. A KDE app built for KDE 3.5.0 will work  on all
KDE 3.5.x 
releases (but not on KDE 3.4.x or 3.3.x). An app built for
KDE 3.5.3 mig
ht not work (depends on case by case) on KDE 3.5.0, 3.5.1,
3.5.2, but wi
ll work on 3.5.3, 3.5.4 ... 
3.5.9. Same if you want to support KDE 3.4. (built against
3.4.0 will 
work on all 3.4.x AND 3.5.x releases). Just that in that
case building 
of an application from KDE 3.5 series might fail completely,
so usually
it is recommended to stick with one major KDE version.

Andras



-- 
 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org

_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

On Friday 14 March 2008 11:46, Andras Mantia wrote:
> On Friday 14 March 2008, Silver Salonen wrote:
> > Is it possible to include kdelibs from one path,
and
> > libkommanderwidgets from another? Or tell kdelibs
that it should
> > search for libkommanderwidgets some other place?
May setting
> > KDEDIRS="/MyProgram/libs:$KDEDIRS"
suffice?
> 
> Yes, you can do something like that. With the notice,
that you don't nee
> d to add "libs" to the path.
> E.g your KDE is in /opt/kde3 and KDEDIRS=/opt/kde3 by
default.
> You install Kommander in /opt/kommander, than you
need:
> KDEDIRS=/opt/kommander:$KDEDIRS
> prior to run kmdr-executor. But this is valid only for
plugin libs,
> for "real" libraries, you need to change
LD_LIBRARY_PATH
> as well:
> LD_LIRBARY_PATH=/opt/kommander/lib:$LD_LIBRARY_PATH

I echoed the output of 'set' via kdialog and did not have
anything related to 
KDE paths in there :(

> > So, which libraries are really incompatible? Can
any version of
> > kdelibs (and its dependencies) be used?
> 
> See above. A KDE app built for KDE 3.5.0 will work  on
all KDE 3.5.x 
> releases (but not on KDE 3.4.x or 3.3.x). An app built
for KDE 3.5.3 mig
> ht not work (depends on case by case) on KDE 3.5.0,
3.5.1, 3.5.2, but wi
> ll work on 3.5.3, 3.5.4 ... 
> 3.5.9. Same if you want to support KDE 3.4. (built
against 3.4.0 will 
> work on all 3.4.x AND 3.5.x releases). Just that in
that case building 
> of an application from KDE 3.5 series might fail
completely, so usually
> it is recommended to stick with one major KDE version.

OK, I see. I think I just won't include Kommander into the
package and let the 
user choose whether to install himself Kommander to use the
Kommander script 
(and leave the shell-script as a fallback).
Including Kommander would be just too fragile and will make
the package at 
least 2 times as big.

I'll leave figuring out the Kommander PBI to somebody more
experienced with 
KDE libs and stuff 

Anyway, thanks a lot for the explanations!

-- 
Silver
_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

On Friday 14 March 2008 2:46:11 am Andras Mantia wrote:
> Hi,
>
> On Friday 14 March 2008, Silver Salonen wrote:
> > I
> > have KDE 3.5.9, but when some other user installes
the PBI, he should
> > be able to use the program as well (even if he
doesn't have Kommander
> > installed at all or has a very minimal KDE
installation). Hence the
> > need for all incompatible libraries to be included
in the package.
> > It's a sort of chroot for the program, but
achieved by setting
> > suitable path-variables.
>
> I see, but this will be challenging, as KDE libraries
are not that small
> and might depend on other libs. But if you know the
klick project
> (http://klik.atekon.de/),
they do something similar.

And of course this why source is so great. 
Paradoxically once Kommander is 
installed it will run any Kommander program and all these
issues become non 
issues. If you want to retain compatibility for older
versions of Kommander 
to run Kommander programs see our change log, but ideally
install the new 
one.
>
[..]
> > >  Speaking of .la files, they are libtool
archives, giving
> > > information about shared libraries and their
dependencies. You
> > > should never need to modify them, they are
created correctly at
> > > build time.
> >
> > If they have information about where to include
libraries from, I
> > guess that's where I can tweak where to include
Kommander-specific
> > stuff and all the other libraries needed?
>
> I doubt modifying .la files is a good idea. Try first
with changing only
> the environment variables (KDEDIRS, LD_LIBRARY_PATH,
PATH).

These are generated files. You would need to be certain you
were dealing with 
binary compatible files and there is nothing here that can't
be managed in 
the build system. I can't imagine a developer modifying
these for a lot of 
reasons. Like I say, you would need to be certain about
anything you did here 
and it would be an admission your build system was really
painful. 
>
> The problem is if you install your PBI onto a computer
that has an older
> KDE, it can easily break. So you have to decide what
KDE to support.
> E.g you want to support KDE 3.5.x (x is from 0 to 9).
In that case you
> need to build Kommander against KDE 3.5.0 when you
create your
> PBI.

Here's a piece of good news. I need to update my wife's
system because I 
pretty much installed it and she pretty much forgot to
maintain or ask for 
maintenance. It turns out when a Gentoo install gets really
stale and you 
miss key update configurations you may as well reinstall. So
she is running 
Kommander SVN on KDE 3.4x. I don't think you will have a lot
of trouble with 
KDE libraries as long as you have the Kommander libraries
right.
>
> > So, which libraries are really incompatible? Can
any version of
> > kdelibs (and its dependencies) be used?
>
> See above. A KDE app built for KDE 3.5.0 will work  on
all KDE 3.5.x
> releases (but not on KDE 3.4.x or 3.3.x). An app built
for KDE 3.5.3 mig
> ht not work (depends on case by case) on KDE 3.5.0,
3.5.1, 3.5.2, but wi
> ll work on 3.5.3, 3.5.4 ...
> 3.5.9. Same if you want to support KDE 3.4. (built
against 3.4.0 will
> work on all 3.4.x AND 3.5.x releases). Just that in
that case building
> of an application from KDE 3.5 series might fail
completely, so usually
> it is recommended to stick with one major KDE version.
>
> Andras
Of course Andras is right, given that the 3.5x series is at
3.5.9. I already 
figure any system as stale as my wife's needs to build from
source regardless 
as it will not be suppored with binaries, even if it were
running a binary 
distribution.


-- 
Eric Laffoon
Project Lead - kdewebdev module
_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander

On Friday 14 March 2008 3:31:44 am Silver Salonen wrote:
> On Friday 14 March 2008 11:46, Andras Mantia wrote:
> > On Friday 14 March 2008, Silver Salonen wrote:
> > > Is it possible to include kdelibs from one
path, and
> > > libkommanderwidgets from another? Or tell
kdelibs that it should
> > > search for libkommanderwidgets some other
place? May setting
> > > KDEDIRS="/MyProgram/libs:$KDEDIRS"
suffice?
> >
> > Yes, you can do something like that. With the
notice, that you don't nee
> > d to add "libs" to the path.
> > E.g your KDE is in /opt/kde3 and KDEDIRS=/opt/kde3
by default.
> > You install Kommander in /opt/kommander, than you
need:
> > KDEDIRS=/opt/kommander:$KDEDIRS
> > prior to run kmdr-executor. But this is valid only
for plugin libs,
> > for "real" libraries, you need to change
LD_LIBRARY_PATH
> > as well:
> >
LD_LIRBARY_PATH=/opt/kommander/lib:$LD_LIBRARY_PATH
>
> I echoed the output of 'set' via kdialog and did not
have anything related
> to KDE paths in there :(
>
> > > So, which libraries are really incompatible?
Can any version of
> > > kdelibs (and its dependencies) be used?
> >
> > See above. A KDE app built for KDE 3.5.0 will work
 on all KDE 3.5.x
> > releases (but not on KDE 3.4.x or 3.3.x). An app
built for KDE 3.5.3 mig
> > ht not work (depends on case by case) on KDE
3.5.0, 3.5.1, 3.5.2, but wi
> > ll work on 3.5.3, 3.5.4 ...
> > 3.5.9. Same if you want to support KDE 3.4. (built
against 3.4.0 will
> > work on all 3.4.x AND 3.5.x releases). Just that
in that case building
> > of an application from KDE 3.5 series might fail
completely, so usually
> > it is recommended to stick with one major KDE
version.
>
> OK, I see. I think I just won't include Kommander into
the package and let
> the user choose whether to install himself Kommander to
use the Kommander
> script (and leave the shell-script as a fallback).
> Including Kommander would be just too fragile and will
make the package at
> least 2 times as big.

Are you aware we have executor only source on our site for
download? It's a 
shame of a paradox, because if people have Kommander
installed, and it's part 
of the official KDE packages (for all that's worth any
more), they can accept 
and run any Kommander program with virtually no binary
issues. 
>
> I'll leave figuring out the Kommander PBI to somebody
more experienced with
> KDE libs and stuff 
>
> Anyway, thanks a lot for the explanations!

I used to have to manage all those environment varialbes
when I started 
compiling KDE programs because I was sick of how distros
hacked up their 
binaries. I know Slackware and Debian can optionally install
from source with 
their package system as can RPM distros and I thought BSD
could too. Isn't 
that an option? It eliminates binary issues.

You should be be able to find help from BSD packagers on
this and if there 
isn't a BSD list (I'm sure there is) you could also try the
kde-devel list 
for your questions. I'm sure there are people with
familiarity with the BSD 
packaging system that can get you where you need to go. If
there is anything 
I have learned with free software it is ask the right person
and you can 
accomplish anything.

Best of luck with whatever you're doing.

-- 
Eric Laffoon
Project Lead - kdewebdev module
_______________________________________________
Kommander mailing list
Kommanderkdewebdev.org

http://mail.kdewebdev.org/mailman/listinfo/kommander