Ahmad Khalifa writes:
> Instead, lintian should alert that some symbols are "unversioned".
The problem is that unversioned symbols are often correct. For one, not
every shared library uses symbol versioning; we may want them all to use
symbol versioning, and certainly way more of them do today,
On 29/01/2025 00:01, Russ Allbery wrote:
Ahmad Khalifa writes:
On 28/01/2025 22:28, Sam Hartman wrote:
"Russ" == Russ Allbery writes:
Russ> recollection (it's been a *lot* of years so I'm hoping I'm
Russ> getting this right) is that this interfered with proper
Russ> symbo
Ahmad Khalifa writes:
> On 28/01/2025 22:28, Sam Hartman wrote:
>>> "Russ" == Russ Allbery writes:
>> Russ> recollection (it's been a *lot* of years so I'm hoping I'm
>> Russ> getting this right) is that this interfered with proper
>> Russ> symbol versioning and could cause th
On 28/01/2025 22:28, Sam Hartman wrote:
"Russ" == Russ Allbery writes:
Russ> recollection (it's been a *lot* of years so I'm hoping I'm
Russ> getting this right) is that this interfered with proper symbol
Russ> versioning and could cause the symbols to be resolved weirdly
R
> "Russ" == Russ Allbery writes:
Russ> recollection (it's been a *lot* of years so I'm hoping I'm
Russ> getting this right) is that this interfered with proper symbol
Russ> versioning and could cause the symbols to be resolved weirdly
Russ> in a way that could cause serious bu
Ahmad Khalifa writes:
> But reading that, I don't see how the linker could declare a dynamic
> GLIBC_ symbol without the related library reference.
> In fact, it should choke with "undefined reference" long before outputting
> a .so file. Even when compiling with -nolibc. But there is always a
>
On 27/01/2025 23:14, Russ Allbery wrote:
Ahmad Khalifa writes:
Having said that, lintian is slow enough as a single thread, I'd vote for
downgrading the tag to Pedantic, but not deleting it.
So, I guess I'll say this more explicitly: I am opposed to downgrading the
tag to pedantic. If the tag
Ahmad Khalifa writes:
> On 27/01/2025 18:24, Russ Allbery wrote:
>> Annoying to implement because I think the implementation would have to
>> know what symbols are provided by libc.
> To my knowledge objdump will spit out the symbols with (GLIBC_v*)
Oh, if one can reliably detect libc symbols b
On 27/01/2025 18:24, Russ Allbery wrote:
Marvin Renich writes:
* Russ Allbery [250126 12:47]:
In theory it would be possible to do better in Lintian by scanning the
symbol table to see if the libc dependency is really unneeded. But
doing that sounds at least a little annoying.
Annoying to
Marvin Renich writes:
> * Russ Allbery [250126 12:47]:
>> In theory it would be possible to do better in Lintian by scanning the
>> symbol table to see if the libc dependency is really unneeded. But
>> doing that sounds at least a little annoying.
> Annoying to users of lintian or annoying to i
* Russ Allbery [250126 12:47]:
> In theory it would be possible to do better in Lintian by scanning the
> symbol table to see if the libc dependency is really unneeded. But doing
> that sounds at least a little annoying.
Annoying to users of lintian or annoying to implement? How so?
I thought o
Simon McVittie writes:
> On Sun, 26 Jan 2025 at 09:14:30 -0800, Russ Allbery wrote:
>> maybe it's more common these days to have plugin libraries that aren't
>> linked with libc? Back in the day, it was very rare for people to
>> successfully manage to write code that never called a libc symbol.
On Sun, 26 Jan 2025 at 09:14:30 -0800, Russ Allbery wrote:
> maybe it's more common these days to have plugin libraries
> that aren't linked with libc? Back in the day, it was very rare for people
> to successfully manage to write code that never called a libc symbol.
In ecosystems with a "platfor
Jeremy Bícha writes:
> On Sun, Jan 26, 2025 at 6:28 AM Ahmad Khalifa wrote:
>> The lintian error is a great heads-up and it's up to the reader to
>> decide whether it's a true error to fix or a false-positive to
>> override.
> I have never seen this Lintian error actually be useful. I think an
On 26/01/2025 12:41, Jeremy Bícha wrote:
On Sun, Jan 26, 2025 at 6:28 AM Ahmad Khalifa wrote:
The lintian error is a great heads-up and it's up to the reader to
decide whether it's a true error to fix or a false-positive to override.
I have never seen this Lintian error actually be useful. I
On Sun, Jan 26, 2025 at 6:28 AM Ahmad Khalifa wrote:
> The lintian error is a great heads-up and it's up to the reader to
> decide whether it's a true error to fix or a false-positive to override.
I have never seen this Lintian error actually be useful. I think an
error is far too strong for this
Hi,
unrelated to your question, but there are things that jump out for me:
Am Sat, Jan 25, 2025 at 10:57:26PM -0600, schrieb Steven Robbins:
> The (CMake-generated) link line does have a bunch of options. Nothing jumped
> out at me:
>
> /usr/bin/c++ -fPIC -g -O2
> -ffile-prefix-map=/home/stev
On 26/01/2025 11:19, Andrey Rakhmatullin wrote:
On Sun, Jan 26, 2025 at 11:07:12AM +, Ahmad Khalifa wrote:
I do this to confirm if lintian is correct:
$ objdump -p file.so
...
NEEDED libc.so.6
...
No?
Lintian already says there is no "NEEDED libc.so.6"
On Sun, Jan 26, 2025 at 01:02:25AM -0600, Steven Robbins wrote:
> > I've come to realise the ITK build has 15 libraries that lintian flags with
> > error library-not-linked-against-libc.
>
> Someone suggested to run ldd -r. Okay, so what does this tell me?
>
> $ ldd -r /lib/x86_64-linux-gnu/libI
On Sun, Jan 26, 2025 at 11:07:12AM +, Ahmad Khalifa wrote:
> > The error description seems straightforward. But how does one solve
> > this? I have to assume that the linker would by default link with the
> > libc (?), so perhaps the linker invocation has options that suppress
> > this? What
On 26/01/2025 04:57, Steven Robbins wrote:
I've come to realise the ITK build has 15 libraries that lintian flags with
...
The error description seems straightforward. But how does one solve
this? I have to assume that the linker would by default link with the
libc (?), so perhaps the linke
On Saturday, January 25, 2025 10:57:26 P.M. CST you wrote:
> I've come to realise the ITK build has 15 libraries that lintian flags with
> error library-not-linked-against-libc.
Someone suggested to run ldd -r. Okay, so what does this tell me?
$ ldd -r /lib/x86_64-linux-gnu/libITKColormap-5.4.so
On Sat, Jan 25, 2025 at 10:57:26PM -0600, Steven Robbins wrote:
> I've come to realise the ITK build has 15 libraries that lintian flags with
> error library-not-linked-against-libc.
>
> https://lintian.debian.org/tags/library-not-linked-against-libc.html[1]
>
> The error description seems str
I've come to realise the ITK build has 15 libraries that lintian flags with
error library-not-linked-against-libc.
https://lintian.debian.org/tags/library-not-linked-against-libc.html[1]
The error description seems straightforward. But how does one solve this? I
have to
assume that the lin
24 matches
Mail list logo
