mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Isaac Dunham <idunham@lavabit.com>
To: musl@lists.openwall.com
Subject: Re: error compiling shadow 4.1.5.1
Date: Mon, 20 May 2013 21:49:00 -0700	[thread overview]
Message-ID: <20130520214900.07aeedeb@newbook> (raw)
In-Reply-To: <20130521031431.GO20323@brightrain.aerifal.cx>

On Mon, 20 May 2013 23:14:32 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Mon, May 20, 2013 at 07:58:44PM -0700, Isaac Dunham wrote:
> > On Mon, 20 May 2013 21:17:20 -0300
> > "Matias A. Fonzo" <selk@dragora.org> wrote:
> > > I'm trying to compile shadow 4.1.5.1.  I receive this error:
> >  
> > > http://pastebin.com/raw.php?i=9kzU9hfg
> >  
> > > It seems like some entries are missing in utmp.h:
> > > ut_host, ut_addr/ut_addr_v6, ...

Could you please provide some clarification as to your configuration?
Specifically, whether PAM is installed, if you disabled nscd (ISTR that
being tied in with glibc), and whether musl is installed in parallel
with glibc (it could be picking up stuff from /usr/include).

I get the impression that the configure script is picking
things up when it shouldn't.  Specifically, it "detects" several
features that may be from /usr.

> > 1: musl does not support utmp. A public list of who's logged in is
> > not desired.
> 
> Well the utmp functions are stubs that don't read or write any data,
> but the interfaces are there to facilitate compiling programs that
> expect them to exist. If there are build errors due to stuff being
> missing, we should add it.
> 
> > 2: Just looking at that error, I get the impression that someone
> > either isn't defining a feature-test macro that they should or is
> > omitting a header. AF_INET is defined in sys/socket.h
> 
> Indeed. glibc exposes socket stuff indirectly through some other
> headers, if I'm not mistaken. musl on the other hand avoids pulling in
> additional headers implicitly. If this is indeed the problem, I think
> just adding #include <sys/socket.h> to the file would fix it.

> > 3: I see no indications that the errors are due to ut_* being
> > absent.
> 
> Agreed.

Adding <sys/socket.h> above <netdb.h> helps get it building.
There are still issues...but they show up due to ut_addr_v6 being
detected in struct utmp.
The errors:
utmp.c: In function 'prepare_utmp':
utmp.c:267: error: dereferencing pointer to incomplete type
utmp.c:268: error: dereferencing pointer to incomplete type
utmp.c:268: error: dereferencing pointer to incomplete type
utmp.c:274: error: dereferencing pointer to incomplete type
utmp.c:275: error: dereferencing pointer to incomplete type
utmp.c:275: error: dereferencing pointer to incomplete type
make[2]: *** [utmp.o] Error 1

Lines 265-277:
#ifdef HAVE_STRUCT_UTMP_UT_ADDR_V6
	memcpy (utent->ut_addr_v6,
		&(sa->sin_addr),
		MIN (sizeof (utent->ut_addr_v6),
		     sizeof (sa->sin_addr)));
	} else if (info->ai_family == AF_INET6) {
		struct sockaddr_in6 *sa =
		(struct sockaddr_in6 *)info->ai_addr;
		memcpy (utent->ut_addr_v6,
			&(sa->sin6_addr),
			MIN (sizeof (utent->ut_addr_v6),
			     sizeof (sa->sin6_addr)));
#endif				/* HAVE_STRUCT_UTMP_UT_ADDR_V6 */

And config.h:
/* Define to 1 if `ut_addr_v6' is a member of `struct utmp'. */
#define HAVE_STRUCT_UTMP_UT_ADDR_V6

undefining this makes it build.

But it seems that ut_addr_v6 is a member of struct utmpx, and that
should be enough...

Finally, there's an unconditional use of ruserok; of course they check
whether it returns 0 or 1 on failure, but assume it's present!

Welcome to autoconf, the build system that will make sure you have ANSI
C89 headers, but won't make sure you have a function that never even
made it into POSIX.

And tcb.h is missing, which means shadow won't enable it.

HTH,
Isaac Dunham



  reply	other threads:[~2013-05-21  4:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-21  0:17 Matias A. Fonzo
2013-05-21  2:58 ` Isaac Dunham
2013-05-21  3:14   ` Rich Felker
2013-05-21  4:49     ` Isaac Dunham [this message]
2013-05-21 12:36       ` John Spencer
2013-05-22  0:42         ` Isaac Dunham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130520214900.07aeedeb@newbook \
    --to=idunham@lavabit.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).