[haiku-development] Re: Services Kit Project Setup (was: Beta3 status update)

  • From: Niels Sascha Reedijk <niels.reedijk@xxxxxxxxx>
  • To: Haiku Development <haiku-development@xxxxxxxxxxxxx>
  • Date: Mon, 25 Jan 2021 08:41:58 +0000

Hi,

On Mon, Jan 25, 2021 at 7:45 AM Adrien Destugues
<pulkomandy@xxxxxxxxxxxxx> wrote:


25 janvier 2021 07:59 "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx> a écrit:

Am 19/01/2021 um 10:20 schrieb Adrien Destugues:

I would prefer 3 over 2, because a lot of our code is linking into 
libshared,
including, for example, Tracker code. Which means the APIs in libshared
actually end up being re-exposed as a shared library in libtracker. Oops.
(note: this could be solved by having symbol visibility default to hidden 
and
explicitly define what classes are the visible API of each lib, but gcc2 
does
not have a convenient way to do that).

Only functions/methods that are actually used would end up in the binary, 
and AFAIR, static
libraries don't expose their symbols by default.

We don't get function/method granularity, as the linker can only include or 
exclude
a complete .o file from the linking (we don't use -ffunction-sections to 
qllow it
to split things further). Otherwise, yes, that's correct.

But, for example Tracker uses ColumnListView, which means libcolumnlistview.a 
is
essentially re-exported by libtracker. And i wouldn't be surprised to find 
other
similar cases, as we have accumulated a lot of things in these static 
libraries.

It has caused me problems sometimes with some of my apps, where the wrong 
version
of a method would be called because a system lib included a newer version.

This may or may not be related, but I think there is also a difference
between x86 and x86_64, where I am running into an issue only on
x86_64 when the symbols are hidden with --fvisibility=hidden with the
error symbol `inflateInit2_' in
/(...path...)/liblibz_sys-6c1a1219eabdf974.rlib(inflate.o)" is
referenced by DSO. [1]

I don't understand symbols and linking well enough to explain the
difference between x86 and x86_64 (both gcc8!)

N>

[1] https://github.com/nielx/rust/issues/9

Other related posts: