From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/991 Path: news.gmane.org!not-for-mail From: orc Newsgroups: gmane.linux.lib.musl.general Subject: Re: bug? sysinfo() and getopt_long() misbehavior Date: Fri, 8 Jun 2012 13:27:31 +0800 Message-ID: <20120608132731.042df3b2@sibserver.ru> References: <20120608005148.7d82c40b@sibserver.ru> <20120608031243.GG163@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1339133401 6032 80.91.229.3 (8 Jun 2012 05:30:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 8 Jun 2012 05:30:01 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-992-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 08 07:29:59 2012 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 1ScrlK-0006ew-5r for gllmg-musl@plane.gmane.org; Fri, 08 Jun 2012 07:29:30 +0200 Original-Received: (qmail 13407 invoked by uid 550); 8 Jun 2012 05:29:29 -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 13373 invoked from network); 8 Jun 2012 05:29:25 -0000 In-Reply-To: <20120608031243.GG163@brightrain.aerifal.cx> X-Mailer: claws-mail Xref: news.gmane.org gmane.linux.lib.musl.general:991 Archived-At: On Thu, 7 Jun 2012 23:12:43 -0400 Rich Felker wrote: > On Fri, Jun 08, 2012 at 12:51:48AM +0800, orc wrote: > > I have built a musl-enabled system and encountered some bugs: > > > > - sysinfo() incorrectly works. The result is busybox' free > > misbehaving: > > Thanks for the catch. Apparently the structure definition was bogus > and was not intended for direct use with the linux sysinfo syscall. > It's fixed in git. Thanks! > > > - (did not investigated properly) possible getopt_long() > > misbehavior, or just miscompile. The result is that iptables and > > gnu sed misbehaving at command line arguments: > > % sed -i '/test/d' ttnosuchfile > > sed: can't find label for jump to `tnosuchfile' > > My GNU sed build does not exhibit this behavior. It's linked with an > older musl, but the getopt code has not changed. Is it possible you > did anything odd building musl (editing the makefile/cflags)? Does the > same happen if you static link sed? If your answers to these questions > suggest a problem in musl, I'll rebuild sed and see if I can reproduce > it. > > > % sed '/test/d' -i ttnosuchfile > > sed: can't read -i: No such file or directory > > sed: can't read ttnosuchfile: No such file or directory > > This is to be expected. Options must come before non-option arguments. > The glibc behavior to the contrary is broken and non-conformant. Yes, I expected that glibc encourages wrong behavior. Sorry, that was my fault: I actually *cross-compiled* sed and it's autohell misdetected something during it (as it usually happens). When native-compiling, problem gone away. (I think the same will be with e2fsprogs, their cross-compiled versions die with GPF on target) > > > # iptables -vnL > > iptables v1.4.12.1: unknown arguments found on commandline > > Try `iptables -h' or 'iptables --help' for more information. > > # iptables --version > > iptables v1.4.12.1: unknown arguments found on commandline > > Try `iptables -h' or 'iptables --help' for more information. > > > > Both sed and iptables were compiled with -D_GNU_SOURCE defined. > > > > Unfortunately I don't actually know how to fix these two. > > I'm suspecting something is broken with respect to dynamic linking... > Are you using an old version of binutils? Did you remove or replace > -Bsymbolic-functions with something else? Binutils 2.20, musl compiled with -Bsymbolic-functions. But statically or dynamically linked iptables still rejects to accept arguments. It required ugly fix to work, mostly same as iproute2, removing some non-conformant extensions, correct headers, maybe there is a fault. It also expects somewhere that we have glibc (#ifdef __GLIBC__) headers. Maybe it's code is non-conformant in whole. I will try to see where it fails on host. > > Rich