[lttng-dev] Making 32-bit user-space events on a 64-bit Linux system

[Alexandre Montplaisir]

Hi Daniel,

Interesting, thanks for documenting your adventure! Some little notes:

On 13-10-02 03:07 PM, Thibault, Daniel wrote:
>    [...]
>
>    Closing observations:
>
>    What's the best, easiest way to get the 32-bit versions of popt and uuid?


Some -dev packages are also multiarch, for example I can install
libpopt-dev:amd64 and libpopt-dev:i386 at the same time (on Ubuntu
13.10) and get the "real" .so symlink from the package.

It doesn't seem to be the case with uuid-dev though, I can only have one
version installed at a time. But you can install one, compile what you
need, then switch to the other one.

ia32-libs has long been deprecated, it now simply depends on a bunch of
:i386 libraries. What's sad is that it used to contain both the
libraries and the headers (so the equivalent of the -dev packages) it
shipped, whereas now the cross-arch dev files are a bit harder to get.

>
>    My lttng-tools-32 make ran into trouble with the 'tests/unit' subdirectory (error below).  Is this an actual bug?
>
>   CC     ../../src/bin/lttng-sessiond/session.o
> ../../src/bin/lttng-sessiond/session.c:249:1: erreur fatale: ouverture du fichier de dépendances .deps/../../src/bin/lttng-sessiond/session.Tpo: Aucun fichier ou dossier de ce type
>
>    Why did the lttng-tools make not restrict itself to the lttng-consumerd daemon as requested?

These could be bugs in the build system. It's quite an obscure feature,
so it's not as well-tested...

>    Couldn't the lttng-tools build detect it's running in a 64-bit system and at least try to make a proper 32-bit consumer daemon (and supporting libraries)?  Maybe this could be a configure switch, off by default.

This is hard to do with the current build system. Autotools basically
lets you "build this one thing". If you want to build something 64 bits,
and then something 32 bits, you have to run 'make' twice. And packaging
the result is a nightmare.

>
>    In building the 32-bit consumer daemon, could we skip the with-consumerd64-* options?

You can probably skip those. They are used for the opposite case, where
you want to compile a 32-bit daemon that will use a 64-bit consumer.

>    How many of the lib32 lttng libraries (apart from liblttng-ust, of course) are deletable?  sample_static32 needs liburcu-bp, liburcu-cds, liblttng-ust-tracepoint in order to run; lttng-consumerd needs liburcu and liblttng-ust-ctl.  That's as far as ldd can detect: there could be dlopen calls lurking in there.  Are liblttng-ctl, liblttng-ust-cyg-profile, liblttng-ust-cyg-profile-fast, liblttng-ust-fork, liblttng-ust-java, liblttng-ust-libc-wrapper, liburcu-common, liburcu-mb, liburcu-qsbr, and liburcu-signal superfluous?

The different liblttng-ust-* libraries are used for different features
(cyg-profile, java JNI interface, fork() tracing). If you want the
feature to be available for 32-bit applications, you need the library.
The liburcu ones that are really unused could be deleted, if you want to
take the risk. They are quite small though, is disk space that much of a
problem?

The Debian/Ubuntu packages for liblttng-ust and liburcu are
multiarch-enabled, so you can install the :i386 and :amd64 versions in
parallel. That way they will be tracked by the package manager, and
won't "linger around".


Hope this helps,
Alexandre