Pandora Fake Absolute Path In Pnd?

[daniel3000]

Hi all,

now trying to pack galculator into a PND.
It compiles nicely, but when I try to execute it without a "make install", it quits because it cannot find the glade files in /usr/local/share/...

The path to the glade files does not seem to be set in the galculator source, but probably the glade lib has this path compiled in.

I rather would not want to modify and recompile libraries here.

Is there any known way to fool galculator, when packed into a PND, that the glade files, which would be somewhere inside the PND, are accessible using an absolute path such as /usr/local/share/...?

Thanks,
Daniel

 

[sebt3]

Hi all,

now trying to pack galculator into a PND.
It compiles nicely, but when I try to execute it without a "make install", it quits because it cannot find the glade files in /usr/local/share/...

The path to the glade files does not seem to be set in the galculator source, but probably the glade lib has this path compiled in.

I rather would not want to modify and recompile libraries here.

Is there any known way to fool galculator, when packed into a PND, that the glade files, which would be somewhere inside the PND, are accessible using an absolute path such as /usr/local/share/...?

Thanks,
Daniel

In most linux apps, path for files (UI definition, images, icons etc) are hard-coded at build time.

As galculator use autoconf/automake and you are cross-compiling, I would use something like this :

# Create target directory
sudo mkdir /mnt/utmp
sudo chown $USER /mnt/utmp

# cleaning current build
make distclean

# Setting cross-compilling build environement
export PATH="$PATH:$PNDSDK/bin:$PNDSDK/usr/bin"
export CFLAGS="-O3 -pipe -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -ftree-vectorize -ffast-math" CPPFLAGS="-I$PNDSDK/usr/include" LDFLAGS="-L$PNDSDK/usr/lib -Wl,-rpath,$PNDSDK/usr/lib"

# Setting the projets
export PRJ=galculator
export LDFLAGS="-L/mnt/utmp/$PRJ/lib -Wl,-rpath,/mnt/utmp/$PRJ/lib $LDFLAGS" CPPFLAGS="$CPPFLAGS -I/mnt/utmp/$PRJ/include" PKG_CONFIG_PATH="$PNDSDK/usr/lib/pkgconfig:/mnt/utmp/$PRJ/lib/pkgconfig"

# Configuring for cross-compilling :
./configure --host=arm-none-linux-gnueabi --with-gnu-ld --prefix=/mnt/utmp/$PRJ
make -j3
make install

The magic is to set the prefix to where this will be mounted at run-time

then you just have to create the PXML.xml file in /mnt/utmp/galculator and create the PND

 

[daniel3000]

[
n most linux apps, path for files (UI definition, images, icons etc) are hard-coded at build time.

As galculator use autoconf/automake and you are cross-compiling, I would use something like this :

I am not crosscompiling, but (at least by now) always natively compiling on the Pandora

./configure --prefix=/mnt/utmp/$PRJ

The magic is to set the prefix to where this will be mounted at run-time

I considered this, too, but this would mean that the PND would not run anymore in case the mountpoint changes.
In the current version of the Pandora Angstrom OS this won't happen, but maybe the PND system is ported to other systems / incorporated into other distributions, or in some later version the PND file systems are mounted elsewhere.
I would rather not be dependent on the exact mountpoint actually.
But as a short-term solution this should work. Maybe, if no other solution is known or comes to my mind, I will use your solution.


Thanks!

Daniel

 

[sebt3]

I am not crosscompiling, but (at least by now) always natively compiling on the Pandora

Ohh sorry

I considered this, too, but this would mean that the PND would not run anymore in case the mountpoint changes.
In the current version of the Pandora Angstrom OS this won't happen, but maybe the PND system is ported to other systems / incorporated into other distributions, or in some later version the PND file systems are mounted elsewhere.
I would rather not be dependent on the exact mountpoint actually.

Then none of my pnd will work then :
Audacious and deadbeef have their plugin-path hardcoded this way.
Every GTK apps are hardcoded this for icons/images loading.

Look autoconf defines this for deadbeef : -DLIBDIR="/mnt/utmp/deadbeef/lib" -DPREFIX="/mnt/utmp/deadbeef" -DDOCDIR="/mnt/utmp/deadbeef/share/doc/deadbeef"
and even libtool provide scripts for that.

This is standard (at least it very look like it). I'm not going to patch all the pnd I made to use relatives paths.

You shouldn't worry about that. If the PND system is ported on some other system, they will need to follow the convention set here.

 

[cosam]

So the solution to a problem caused by a hard-coded path is to use... yet another hard-coded path? Sure, folk are of course free to use whatever approach they like and sure, it'll work in this case, but if anything this thread should be a warning against this kind of thing. One of the main benefits of the PND system is that you don't need to know where your package gets mounted. I don't understand why one would want to make assumptions about paths when it's completely unnecessary to do so.

 

[sebt3]

So the solution to a problem caused by a hard-coded path is to use... yet another hard-coded path? Sure, folk are of course free to use whatever approach they like and sure, it'll work in this case, but if anything this thread should be a warning against this kind of thing. One of the main benefits of the PND system is that you don't need to know where your package gets mounted. I don't understand why one would want to make assumptions about paths when it's completely unnecessary to do so.

While I agree with you on the idea, most (to not say all) free software are build this way.
The few exceptions are those packages that have been made portable (gimp and a few others).

I may patch this in my pnds in the futur, but this is messing with upstream and do take time...
For now, what we need is to pump up packages....

 

[dflemstr]

What about "./configure --prefix=."? Works for most packages I've tried.

 

[daniel3000]

What about "./configure --prefix=."? Works for most packages I've tried.

I have tried this on some packages, too,l but all I have tried so far say that they require an absolute path here.
But good to know there are others. So I will keep trying.

While I agree with you on the idea, most (to not say all) free software are build this way.
The few exceptions are those packages that have been made portable (gimp and a few others).

How do they make an application portable? Is it really by changing the code?
Can't there be faked something for the application so it thinks it's using an absolute path?
Using mount -bind or so...?


Daniel