mailing list of musl libc
 help / color / mirror / code / Atom feed
* [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).