Custom builder for a library

PerlMax

Good morning, i could compile the app for amd64 architecture but cross compiling didn't work:

/usr/bin/ld: skipping incompatible /usr/lib/aarch64-linux-gnu/libm.a when searching for -lm
collect2: error: ld returned 1 exit status
make: *** [Makefile:4178: blib/arch/auto/pEFL/pEFL.so] Error 1

Has someone a clue what's the problem here? Ist arm64 the same as aarch64?

And for armfh I get the following error:

In file included from /usr/include/features.h:485,
                 from /usr/include/arm-linux-gnueabihf/sys/types.h:25,
                 from /usr/lib/x86_64-linux-gnu/perl/5.30/CORE/perl.h:697,
                 from lib/pEFL.xs:3:
/usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:11: fatal error: gnu/stubs-soft.h: No such file or directory
    7 | # include <gnu/stubs-soft.h>
      |           ^~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:1057: lib/pEFL.o] Error 1

Thanks in advance,
Max

lduboeuf

@PerlMax
Maybe you will have better luck on the App dev Telegram channel https://t.me/UbuntuAppDevEN

and sharing your project's repo will help

PerlMax

I could built the lib, but starting doesn't work:

Launching app
terminate called after throwing an instance of 'std::runtime_error'
  what():  Lost our connection with the registry
-bash: line 1: 151018 Aborted                 lomiri-app-launch hellopefl.maxperl_hellopefl_1.0.0
Started: hellopefl.maxperl_hellopefl_1.0.0
ADB_COMMAND_FAILED

How can I start a app from the terminal, so that I can see error messages?

Thanks for the hint for the dev group, I will look into it the next days...

Best wishes
Max

dobey

@PerlMax said in Custom builder for a library:

How can I start a app from the terminal, so that I can see error messages?

Running clickable logs should let you see the log messages for your app, if there are any. However, given what you've posted already, it seems you are running a bash script, which runs some other process, which has hit a SIGABRT condition.

Perl is not really a supported language for building UT applications, so we'd need to see your code (preferably in a git repository) to be able to help much further. Whatever you are running on the first line of your script is failing. If it is perl, then you might want to also check the system log on your device (/var/log/syslog) for possible apparmor DENIALs.

PerlMax

Hello everybody,

I am trying again to develop a simple pEFL test app. In libertine everything works great. Unfortunately the app won't start outside the libertine environment. Apparently, efl needs to be able to read files in the $HOME directory and some other directories (see https://sourceforge.net/p/enlightenment/mailman/message/58751741/).

My idea now is to run the app in a chroot environment. Would that be possible for a normal click app? Are there any examples of other apps that do this? Or is that not such a good idea?

Thanks in advance!
Max

projectmoon

@PerlMax said:

Hello everybody,

I am trying again to develop a simple pEFL test app. In libertine everything works great. Unfortunately the app won't start outside the libertine environment. Apparently, efl needs to be able to read files in the $HOME directory and some other directories (see https://sourceforge.net/p/enlightenment/mailman/message/58751741/).

My idea now is to run the app in a chroot environment. Would that be possible for a normal click app? Are there any examples of other apps that do this? Or is that not such a good idea?

Thanks in advance!
Max

You can make the application unconfined (not recommended), or use the read_path/write_path options in the apparmor file. Or, potentially better, change the library/application to read from the UT XDG data-dirs correctly.

PerlMax

@projectmoon Unfortunately this is not enough. The c library searches for config files etc. under the installation prefix (e.g. /usr/share/elementary). Perhaps it would be possible to compile efl at the UT XDG data-dir, but I didn't have luck with this so far That's why the solution would be to run in a chroot environment (where I could copy the files from the libertine container.. Best wishes, Max

projectmoon

@PerlMax said:

@projectmoon Unfortunately this is not enough. The c library searches for config files etc. under the installation prefix (e.g. /usr/share/elementary). Perhaps it would be possible to compile efl at the UT XDG data-dir, but I didn't have luck with this so far That's why the solution would be to run in a chroot environment (where I could copy the files from the libertine container.. Best wishes, Max

I mean, if it uses an installation prefix, you should be able to change the prefix to anything you want. What happens if you try to compile it to an XDG data-dir?

developerbayman

so im reading and my AI : I would not use a chroot for this in a normal confined Click app.

A real chroot() needs privilege/CAP_SYS_CHROOT, and even inside a chroot the process would still be under the same Ubuntu Touch AppArmor confinement. So it would not really solve the app-store/confined-app problem; it would mostly move the path problem somewhere harder to debug.

For EFL/pEFL the better confined solution is to make the Click package look like the EFL install prefix at runtime:

build/install EFL and pEFL into the Click package, for example under usr/
ship the needed usr/share/elementary, usr/share/efreet, locale files, Perl module files, and .so files with the app
start the app through a wrapper script that redirects EFL, XDG, Perl, and HOME paths into the app’s own confined directories

Example launcher idea:

#!/bin/sh
set -eu

APP_DIR="$(CDPATH= cd -- "$(dirname -- "$0")" && pwd)"
APP_ID="hellopefl.maxperl"

APP_HOME="/home/phablet/.local/share/${APP_ID}"
APP_CACHE="/home/phablet/.cache/${APP_ID}"
APP_CONFIG="/home/phablet/.config/${APP_ID}"

mkdir -p "$APP_HOME" "$APP_CACHE" "$APP_CONFIG"
mkdir -p "$APP_HOME/.cache/efreet"
mkdir -p "$APP_HOME/.elementary/config"

export HOME="$APP_HOME"
export XDG_DATA_HOME="$APP_HOME/.local/share"
export XDG_CACHE_HOME="$APP_CACHE"
export XDG_CONFIG_HOME="$APP_CONFIG"
export XDG_DATA_DIRS="$APP_DIR/usr/share:/usr/local/share:/usr/share"

export ELM_PREFIX="$APP_DIR/usr"
export ELM_BIN_DIR="$APP_DIR/usr/bin"
export ELM_LIB_DIR="$APP_DIR/usr/lib/aarch64-linux-gnu"
export ELM_DATA_DIR="$APP_DIR/usr/share/elementary"
export ELM_LOCALE_DIR="$APP_DIR/usr/share/locale"

export LD_LIBRARY_PATH="$APP_DIR/usr/lib/aarch64-linux-gnu:$APP_DIR/lib/aarch64-linux-gnu:${LD_LIBRARY_PATH:-}"
export PERL5LIB="$APP_DIR/usr/lib/aarch64-linux-gnu/perl5:$APP_DIR/usr/share/perl5:${PERL5LIB:-}"

exec "$APP_DIR/usr/bin/hellopefl" "$@"

The important bit is that /usr/share/elementary should become $APP_DIR/usr/share/elementary inside the Click package, and EFL should be told about that prefix with the ELM_* variables instead of trying to read/write the real device /usr or /home/phablet.

For Clickable, the rough shape would be:

builder: cmake
framework: ubuntu-touch-24.04-1.x

dependencies_host:
  - perl
  - make
  - pkg-config

dependencies_target:
  - libefl-all-dev

libraries:
  pEFL:
    builder: custom
    src_dir: libs/pEFL
    build:
      - cd "$SRC_DIR" && perl Makefile.PL INSTALL_BASE="$INSTALL_DIR/usr"
      - cd "$SRC_DIR" && make
      - cd "$SRC_DIR" && make install

install_data:
  "${PEFL_LIB_INSTALL_DIR}/usr": "usr"

install_root_data:
  - run-pefl.sh

install_lib:
  - "libefl.so*"
  - "libelementary.so*"
  - "libeina.so*"
  - "libevas.so*"
  - "libecore*.so*"
  - "libedje.so*"
  - "libefreet.so*"

That example will need the exact library list adjusted after running ldd on the final binary/module, but the direction is: bundle the runtime prefix, then point EFL and Perl at the bundled prefix.

read_path/write_path can help for specific paths, but I would treat that as a last resort. A confined app should work from its own packaged resources and its own .config, .cache, and .local/share directories.

A helper app/broker such as Workspace could be useful during development for copying logs, staging files, checking AppArmor denials, or preparing the bundle, but I would not make the final pEFL app depend on an unconfined/root broker just to launch. That would be useful for side-loaded developer/admin workflows, not the clean confined Click solution.

developerbayman

i know this is old but i think its cool when it does that lol ...shows me its paying attention ....3 years+ in the making