Ports: ObjFW usability issues

[ADKaster]

When we install the ObjFW port there's a few issues:

• It does not list llvm as a required dependency
• The installed scripts, objfw-compile, objfw-embed and objfw-config are prefixed with x86_64-pc-serenity- which is a bit awkward for what will be a native compiler on the target.
• The objfw-config script lists OBJCC as x86_64-pc-serenity-clang, which is not what the installed port of Clang will be on the target (it's just /usr/local/bin/clang as installed)

This is probably(?) because we compile it with x86_64-pc-serenity-clang on the host, but that doesn't line up with what the environment will be at runtime.

The scripts also use if !, which is not supported by /bin/Shell --posix, but Ali mentioned to me on discord that he was already looking at that one as a bug report to Shell.

cc @bugaevc @Midar

[ADKaster]

FWIW to build with clang as the cross-compiler going:

# Get a serenity build built with clang 16.0.6
./Meta/serenity.sh run x86_64 Clang 
# Setup shell for building Clang ports
export SERENITY_TOOLCHAIN=Clang
# Build ports
cd Ports/ObjFW && ./package.sh
cd Ports/llvm && ./package.sh
# If no shell fix yet, edit Meta/build-root-filesystem.sh line 195-196 to:
#   printf "installing shortcuts... "
#   ln -sf /usr/local/bin/bash mnt/bin/sh
# and install Bash:
cd Ports/bash && ./package.sh

(not being able to remount /bin /bin as rw anymore is also a separate issue 😬 )

[Midar]

Ah, that's a very interesting point. Usually, these tools are used in order to cross-compile applications using ObjFW, so they keep the host triple. It's not often that you cross-compile ObjFW itself, but then build an application on the "host" rather than the "build". objfw-config is probably also going to give output not suitable for running on "host" rather than "build".

How is this handled for other ports that use autoconf?

[bugaevc]

Usually, these tools are used in order to cross-compile applications using ObjFW, so they keep the host triple. It's not often that you cross-compile ObjFW itself

I'd expect ObjFW to respect build/host/target machine options. In this case, we have:

• build -- some Unix system (for example x86_64-linux-gnu)
• host -- x86_64-pc-serenity
• target -- x86_64-pc-serenity

As I understand it, currently the ports script passes --host=x86_64-pc-serenity to ObjFW's configure. So that certainly should tell ObjFW that it is going to run on Serenity, not on the "host" (as in build).

[bugaevc]

That being said, it is a bit unclear how we want this to work. Do we want to use this to cross-compile more ObjFW-using software from the "host" to Serenity? Do we want to compile more software on Serenity, using ObjFW?

[alimpfard]

The scripts also use if !, which is not supported by /bin/Shell --posix, but Ali mentioned to me on discord that he was already looking at that one as a bug report to Shell.

Should be fixed by #20279.

[ADKaster]

That being said, it is a bit unclear how we want this to work. Do we want to use this to cross-compile more ObjFW-using software from the "host" to Serenity? Do we want to compile more software on Serenity, using ObjFW?

Well, the way the port is currently setup, it will compile with --target and --host as serenity. If we wanted to have --host as your standard Unix system and --target as serenity for a true cross-compiler, rather than a cross-build, we would have to change the port script to accommodate that. The default configopts set --host to serenity.

I think for most compiler tools we want the ability to do both, but It's not clear how to set that up properly without sprinkling more and more shell scripts in Toolchain/

[Midar]

Thinking of it some more, I don't think it's even possible to cross-compile it and then use the host compiler on the host. Because when doing this, it never ever sees the host compiler, so knows nothing about it. configure cannot check for flags, bugs, etc. in the host compiler this way. I think not even canadian cross allows this for GNU tools.