Building programs with MODE=shared in L4Re

[Adam Lackorzynski]

Hi Paul,

On Fri May 11, 2018 at 01:00:11 +0200, Paul Boddie wrote:
> I have been busy writing libraries and programs for L4Re and recently had to 
> think about the size of the payloads I have been deploying. It appears that in 
> the build system, one can use MODE=shared to build dynamically-linked 
> programs, and there is a shared version of the hello example in the examples 
> package.
>
> However, I don't see any recipe for doing this for other programs. My 
> impression is that the dynamic linker must have all the required libraries 
> deployed as modules, and so I wrote a script to generate a list of such 
> modules using readelf. In addition, it appears that libl4sys-direct.so is 
> required (which readelf does not detect).

It's option that available but on default most/all programs are static.
 
> Adding these modules to my conf/modules.list should yield success, but within 
> my constrained debugging environment, I only see that "shared" programs fail 
> to start. I really need to see if they start but then experience some 
> initialisation problem, or whether they actually crash but Mag keeps their 
> viewports around.
> 
> Are there any other things that I need to consider when building and deploying 
> such programs? I searched for guidance on this topic and only found the 
> following:
> 
> http://os.inf.tu-dresden.de/pipermail/l4-hackers/2014/007094.html
> http://os.inf.tu-dresden.de/pipermail/l4-hackers/2016/007830.html
> 
> Both of these discussion threads only provide some details and are obviously 
> not tutorials.
> 
> Thanks for any clues you might be able to provide!

You can set LD_DEBUG=1 in the environment of your program to make the
dynamic loader tell you something. LD_TRACE_LOADED_OBJECTS=1 might also
be of help. Add enviroment variable settings after the program's
cmdline: ...:start({ ...}, "rom/myprog arg", { LD_DEBUG=1, ... });

Adam

> P.S. I guess I could also see if the CI20 produces useful console-level 
> details, perhaps indicating an architecture-related problem. Usually, however, 
> the problem is caused by some simple mistake I have made, so I suspect that 
> there is merely some detail I have forgotten.