* [musl] sgetspent(3) on musl
@ 2024-11-27 12:10 Alejandro Colomar
2024-11-29 6:11 ` Rich Felker
0 siblings, 1 reply; 5+ messages in thread
From: Alejandro Colomar @ 2024-11-27 12:10 UTC (permalink / raw)
To: Rich Felker, musl
[-- Attachment #1: Type: text/plain, Size: 472 bytes --]
Hi Rich,
Link: <https://github.com/shadow-maint/shadow/pull/1115#issuecomment-2466994769>
There seems to be a prototype for sgetspent(3) on musl libc, but I don't
find an definition. The prototype is there since commit 0. Is that a
bug? (It looks like a bug, unless I'm missing something.) This results
in linker errors. Should the prototype be removed, or the definition be
added?
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] sgetspent(3) on musl
2024-11-27 12:10 [musl] sgetspent(3) on musl Alejandro Colomar
@ 2024-11-29 6:11 ` Rich Felker
2024-11-29 6:35 ` Jeffrey Walton
2024-11-29 12:22 ` Alejandro Colomar
0 siblings, 2 replies; 5+ messages in thread
From: Rich Felker @ 2024-11-29 6:11 UTC (permalink / raw)
To: Alejandro Colomar; +Cc: musl
On Wed, Nov 27, 2024 at 01:10:20PM +0100, Alejandro Colomar wrote:
> Hi Rich,
>
> Link: <https://github.com/shadow-maint/shadow/pull/1115#issuecomment-2466994769>
>
> There seems to be a prototype for sgetspent(3) on musl libc, but I don't
> find an definition. The prototype is there since commit 0. Is that a
> bug? (It looks like a bug, unless I'm missing something.) This results
> in linker errors. Should the prototype be removed, or the definition be
> added?
I think having the declaration there is just an oversight. Unless
we've encountered things that need the missing function, we should
probably just remove the declaration.
FWIW though I don't generally expect spurious declarations like this
to do any harm -- detection should be via a compile-and-link test not
just looking for a declaration. Is there a build system these days
that's doing purely declaration-based detection?
Rich
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] sgetspent(3) on musl
2024-11-29 6:11 ` Rich Felker
@ 2024-11-29 6:35 ` Jeffrey Walton
2024-11-29 12:29 ` Alejandro Colomar
2024-11-29 12:22 ` Alejandro Colomar
1 sibling, 1 reply; 5+ messages in thread
From: Jeffrey Walton @ 2024-11-29 6:35 UTC (permalink / raw)
To: musl; +Cc: Alejandro Colomar
On Fri, Nov 29, 2024 at 1:12 AM Rich Felker <dalias@libc.org> wrote:
>
> [...]
> FWIW though I don't generally expect spurious declarations like this
> to do any harm -- detection should be via a compile-and-link test not
> just looking for a declaration. Is there a build system these days
> that's doing purely declaration-based detection?
I don't know about build systems, but I generally avoid build systems
for my projects. I would not wish Autotools on an enemy.
Instead I use a non-anemic make, like GNU Make. GNU Make is all that
is needed to test header files for #defines.
Jeff
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] sgetspent(3) on musl
2024-11-29 6:11 ` Rich Felker
2024-11-29 6:35 ` Jeffrey Walton
@ 2024-11-29 12:22 ` Alejandro Colomar
1 sibling, 0 replies; 5+ messages in thread
From: Alejandro Colomar @ 2024-11-29 12:22 UTC (permalink / raw)
To: Rich Felker; +Cc: musl
[-- Attachment #1: Type: text/plain, Size: 2148 bytes --]
Hi Rich,
On Fri, Nov 29, 2024 at 01:11:44AM -0500, Rich Felker wrote:
> On Wed, Nov 27, 2024 at 01:10:20PM +0100, Alejandro Colomar wrote:
> > Hi Rich,
> >
> > Link: <https://github.com/shadow-maint/shadow/pull/1115#issuecomment-2466994769>
> >
> > There seems to be a prototype for sgetspent(3) on musl libc, but I don't
> > find an definition. The prototype is there since commit 0. Is that a
> > bug? (It looks like a bug, unless I'm missing something.) This results
> > in linker errors. Should the prototype be removed, or the definition be
> > added?
>
> I think having the declaration there is just an oversight. Unless
> we've encountered things that need the missing function, we should
> probably just remove the declaration.
Well, in shadow we have a definition for when running in systems that
lack it. I was going to kill it thinking that all systems had it, but
since you don't, I guess it makes more sense to keep it and that you
just remove your prototype.
I think glibc shouldn't have added it either. This is stuff for a
libshadow, and not for libc, IMO.
>
> FWIW though I don't generally expect spurious declarations like this
> to do any harm
They confuse people like me who assume that if I see a declaration it
means there's a definition. That's what I do with glibc, since finding
their definition of things is not a trivial task. In musl, I should
have checked that there was no definition, since you usually have it
easy to find, but I didn't conceive the possibility of a prototype
without a definition. :)
Since I found "something" and I found it in every libc that I need to
care, I just assumed it exists, without a build-system check. Thanks to
having CI that builds on Alpine, I noticed in time that something was
wrong, but it could have been worse.
> -- detection should be via a compile-and-link test not
> just looking for a declaration. Is there a build system these days
> that's doing purely declaration-based detection?
Probably not; just human brains. :)
Have a lovely day!
Alex
> Rich
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [musl] sgetspent(3) on musl
2024-11-29 6:35 ` Jeffrey Walton
@ 2024-11-29 12:29 ` Alejandro Colomar
0 siblings, 0 replies; 5+ messages in thread
From: Alejandro Colomar @ 2024-11-29 12:29 UTC (permalink / raw)
To: Jeffrey Walton; +Cc: musl
[-- Attachment #1: Type: text/plain, Size: 1690 bytes --]
Hi Jeffrey,
On Fri, Nov 29, 2024 at 01:35:06AM -0500, Jeffrey Walton wrote:
> On Fri, Nov 29, 2024 at 1:12 AM Rich Felker <dalias@libc.org> wrote:
> >
> > [...]
> > FWIW though I don't generally expect spurious declarations like this
> > to do any harm -- detection should be via a compile-and-link test not
> > just looking for a declaration. Is there a build system these days
> > that's doing purely declaration-based detection?
>
> I don't know about build systems, but I generally avoid build systems
> for my projects. I would not wish Autotools on an enemy.
+1
> Instead I use a non-anemic make, like GNU Make.
I agree, and use only GNU Make for my own software projects.
<https://git.kernel.org/pub/scm/libs/liba2i/liba2i.git/tree/GNUmakefile>
<https://git.kernel.org/pub/scm/libs/liba2i/liba2i.git/tree/share/mk>
Here's an example of feature testing in my makefiles:
CC_HAS_FFAT_LTO_OBJECTS := \
$(shell \
$(CC) -Werror -ffat-lto-objects -S -x c -o /dev/null /dev/null $(HIDE_ERR) \
&& $(ECHO) yes \
|| $(ECHO) no; \
)
<https://git.kernel.org/pub/scm/libs/liba2i/liba2i.git/tree/share/mk/configure/build-depends/gcc/cc.mk#n30>
> GNU Make is all that
> is needed to test header files for #defines.
Yep. However, when testing for a libc function, I think I would most
likely run CC without flags asking to only compile but not assemble or
link. I would just do the full compilation, and see if it works.
Although, I can consider that if some make(1)-based build system wants
to save a small amount of time, it might cut on these.
>
> Jeff
Have a lovely day!
Alex
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2024-11-29 12:29 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-11-27 12:10 [musl] sgetspent(3) on musl Alejandro Colomar
2024-11-29 6:11 ` Rich Felker
2024-11-29 6:35 ` Jeffrey Walton
2024-11-29 12:29 ` Alejandro Colomar
2024-11-29 12:22 ` Alejandro Colomar
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).