From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/3843 Path: news.gmane.org!not-for-mail From: Isaac Newsgroups: gmane.linux.lib.musl.general Subject: Update: [pkg-shadow-Bugs][314271] Shadow FTBFS with musl libc Date: Tue, 6 Aug 2013 18:03:59 -0700 Message-ID: <20130807010358.GA7667@newbook> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1375837454 31146 80.91.229.3 (7 Aug 2013 01:04:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Aug 2013 01:04:14 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-3847-gllmg-musl=m.gmane.org@lists.openwall.com Wed Aug 07 03:04:15 2013 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1V6sAh-0003x7-3L for gllmg-musl@plane.gmane.org; Wed, 07 Aug 2013 03:04:15 +0200 Original-Received: (qmail 7362 invoked by uid 550); 7 Aug 2013 01:04:14 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 7351 invoked from network); 7 Aug 2013 01:04:13 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=lavabit; d=lavabit.com; b=c+6gZwUKH8qD/+InmWXna3mSAphqcstxU8+SNR4MWvoIdl/moNqYTJJTeIcoKLxn3ZzUdqFrGiGu5dLDp3d/JLGoUc/46h7x+KVCPpBXHRREkyKDoPFwdjMlLQJIz0ZwO/x33faxrlbf3n63o4u7xsSjJzBGhFF8fd2bKs5iOEM=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type:Content-Disposition:User-Agent; Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) Xref: news.gmane.org gmane.linux.lib.musl.general:3843 Archived-At: Rich, can we make sizeof(struct in_addr) visible? That's ostensibly the only thing necessary for shadow to build at present. ----- Forwarded message from pkg-shadow-bugs@alioth.debian.org ----- Date: Wed, 07 Aug 2013 00:23:43 +0000 From: pkg-shadow-bugs@alioth.debian.org To: noreply@alioth.debian.org Subject: [pkg-shadow-Bugs][314271] Shadow FTBFS with musl libc pkg-shadow-Bugs item #314271 was changed at 07/08/2013 02:23 by Nicolas Fran??ois You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=411478&aid=314271&group_id=30580 >Status: Closed Priority: 3 Submitted By: Isaac Dunham (idunham-guest) Assigned to: Nobody (None) Summary: Shadow FTBFS with musl libc Category: None Group: None >Resolution: Fixed Initial Comment: I attempted to build shadow 4.1.5.1 with musl libc (http://www.musl-libc.org/), and ran into a few issues: 1: missing in libmisc/utmp.c glibc includes several headers from ; is one of these. 2: libmisc/utmp.c assumes that member sin_addr of struct sockaddr_in (type struct in_addr) is completely defined. musl has a policy of not making implementation-specific details public unless necessary; this is the full definition: struct sockaddr_in { sa_family_t sin_family; in_port_t sin_port; struct in_addr sin_addr; uint8_t sin_zero[8]; }; However, upstream may be willing to change this. WORKAROUND: export ac_cv_member_struct_utmp_ut_addr_v6=no ac_cv_member_struct_utmpx_ut_addr_v6=no before running configure. -need to make ruserok conditional. ruserok is a nonstandard function, but it is not checked for, and musl does not currently implement it. The proper solution would be to check for it in configure and either disable that codepath or else add a stub/alternate implementation. There is no __MUSL__-type macro; upstream's view is that any implementation-specific details may be changed at any point so this is a short-term fix at best. STEPS TO REPRODUCE: git clone git://git.musl-libc.org/musl cd musl /configure --prefix=/opt/musl --bindir=/opt/musl/bin make su -c "make install" root cd .. #go to the shadow source directory. CC=/opt/musl/bin/musl-gcc \ /configure --without-nscd --without-libpam make ---------------------------------------------------------------------- >Comment By: Nicolas Fran??ois (nekral) Date: 07/08/2013 02:23 Message: Point 1 is fixed. ruserok is now checked by configure (not tested) Regarding point 2, I don't think I can do without knowing the size of what I copy. I can find quite some hits on Google for sizeof(struct in_addr) so maybe it's needed for users. ---------------------------------------------------------------------- You can respond by visiting: https://alioth.debian.org/tracker/?func=detail&atid=411478&aid=314271&group_id=30580 ----- End forwarded message -----