Error: hammer ABI contains Genode-internal symbol '__bss_start'

Guido Witmond guido at witmond.nl
Wed Jan 16 23:31:24 CET 2019


Hello Norman, Christian,

On 01/15/19 13:11, Norman Feske wrote:
> Hello Guido,
> 
> your posting does not bode well with me.

My sincere apologies if my previous email came across as too harsh. I 
never had the intention to be rude. I think it came from lack of 
knowledge on my side to correctly understand your view.

Your latest response provided lots of background so I think I know where 
our misunderstanding came from.

> ... using an analogy: There is a
> country road that enters a village. At the side of the road, just in
> front of the school, there is a warning sign. The sign is meant to raise
> attention, to prompt drivers to decelerate, to get conscious about the
> situation, and - if everything is clear - to slowly accelerate again.
> 
> You drive this road for the first time. You see the sign, you get
> conscious of the situation, but at this time, no children are crossing
> the road. So your conclusion is to remove the warning sign to make the
> traffic run smoother though the village. I hope you agree that this
> wouldn't be a positive contribution to society. ;-)

I like the analogy, it fits well:

It was my first time on that road. But what you designed as a warning 
sign, felt like a road block to me: I could not build the package to the 
point that I could test it works. I was completely stuck, without any 
road signs (documentation, release notes, emails, blogs) on how to 
navigate around it. So I tried to remove the road block, not to kill 
children, just to get moving :-)

 From the earlier responses, I understood that it is possible to leave 
internal symbols in the ABI-file but it seemed you gravitated to make 
the warning/road-block enforced. Being stuck behind it, I wanted to 
prevent that from happening. Hence my request for convenience. But I 
failed in articulating my view of the road-block.

When I filtered out the blacklist in abi_symbols, I could compile my 
depot package. After some evenings of fruitless struggle, it felt like a 
victory to me. That's when I made the PR. It solved my problem, so I 
assumed it could be of value to you.

[...]

> Someone who offers a
> library should pay attention to the ABI in order to catch errors of
> library users at linking time, not at runtime.

Agree. But I wasn't yet at the stage of offering it to anyone. I still 
needed to compile it.

It took me some iterations to get the recipe files correct. Having to 
review at every cycle - and losing my review work when changing the 
recipes - did not seem attractive to me. So I wanted to postpone the 
ABI-cleanup until my test code could compile against the package.


So I end with a plea to make that warning easily bypassed during package 
development. Not just for me but also for others who start packaging.


Regards, Guido.



More information about the users mailing list