Bug in include/netinet/in.h

Bug in include/netinet/in.h

[Alexander Stadler]

Dear musl developers!

I currently try to compile openwrt with your library instead of with uClibc.

Since recent changes in the netifd code, I get the following error:

make[6]: Entering directory `/space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/netifd-2013-01-22.1'
Scanning dependencies of target netifd
make[6]: Leaving directory `/space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/netifd-2013-01-22.1'
make[6]: Entering directory `/space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/netifd-2013-01-22.1'
[  5%] Building C object CMakeFiles/netifd.dir/main.c.o
[ 11%] Building C object CMakeFiles/netifd.dir/utils.c.o
[ 17%] Building C object CMakeFiles/netifd.dir/system.c.o
[ 23%] Building C object CMakeFiles/netifd.dir/tunnel.c.o
[ 29%] Building C object CMakeFiles/netifd.dir/interface.c.o
[ 35%] Building C object CMakeFiles/netifd.dir/interface-ip.c.o
/space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/netifd-2013-01-22.1/interface-ip.c: In function 'interface_ip_set_ula_prefix':
/space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/netifd-2013-01-22.1/interface-ip.c:655:2: error: suggest parentheses around arithmetic in operand of '|' [-Werror=parentheses]
/space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/netifd-2013-01-22.1/interface-ip.c:655:2: error: suggest parentheses around arithmetic in operand of '|' [-Werror=parentheses]
/space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/netifd-2013-01-22.1/interface-ip.c:655:2: error: suggest parentheses around arithmetic in operand of '|' [-Werror=parentheses]
cc1: all warnings being treated as errors
make[6]: *** [CMakeFiles/netifd.dir/interface-ip.c.o] Error 1
make[6]: Leaving directory `/space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/netifd-2013-01-22.1'

As this line does not have an | operation in it, but IN6_ARE_ADDR_EQUAL
http://git.musl-libc.org/cgit/musl/tree/include/netinet/in.h#n148
has, we think its a bug on your side.

The ticket in openwrt was
https://dev.openwrt.org/ticket/12871

Thanks

Alex

Re: Bug in include/netinet/in.h

[John Spencer]

On 01/23/2013 05:39 PM, Alexander Stadler wrote:
> [-Werror=parentheses]
> /space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/netifd-2013-01-22.1/interface-ip.c:655:2: error: suggest parentheses around arithmetic in operand of '|' [-Werror=parentheses]
> cc1: all warnings being treated as errors
the bug here is -Werror being passed to the compiler, try adding 
--disable-werror to the configure invocation

(note: using -Werror by default is pretty inept, since it will cause 
build errors on any compiler/libc combination that has not yet been 
tested by the package author)

Re: Bug in include/netinet/in.h

[Alexander Stadler]

Am 23.01.2013 17:58, schrieb John Spencer:
> On 01/23/2013 05:39 PM, Alexander Stadler wrote:
>> [-Werror=parentheses]
>> /space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/netifd-2013-01-22.1/interface-ip.c:655:2: error: suggest parentheses around arithmetic in operand of '|' [-Werror=parentheses]
>> cc1: all warnings being treated as errors
> the bug here is -Werror being passed to the compiler, try adding --disable-werror to the configure invocation
> 
> (note: using -Werror by default is pretty inept, since it will cause build errors on any compiler/libc combination that has not yet been tested by the package author)

Thanks for your fast response.

I'll try that, but a really big part of the code compiled through, so don't you think that this specific problem is one which could be optimized to not throw anything?

Re: Bug in include/netinet/in.h

[Rich Felker]

On Wed, Jan 23, 2013 at 05:58:13PM +0100, John Spencer wrote:
> On 01/23/2013 05:39 PM, Alexander Stadler wrote:
> >[-Werror=parentheses]
> >/space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/netifd-2013-01-22.1/interface-ip.c:655:2: error: suggest parentheses around arithmetic in operand of '|' [-Werror=parentheses]
> >cc1: all warnings being treated as errors
> the bug here is -Werror being passed to the compiler, try adding
> --disable-werror to the configure invocation
> 
> (note: using -Werror by default is pretty inept, since it will cause
> build errors on any compiler/libc combination that has not yet been
> tested by the package author)

Normally these kind of warnings are ignored in the system headers and
macro text expanded from macros defined in the system headers. I don't
see any reason we can't "fix" this particular macro however if for
some reason it's still making trouble..

Rich

Re: Bug in include/netinet/in.h

[Alexander Stadler]

Am 23.01.2013 18:11, schrieb Rich Felker:
> On Wed, Jan 23, 2013 at 05:58:13PM +0100, John Spencer wrote:
>> On 01/23/2013 05:39 PM, Alexander Stadler wrote:
>>> [-Werror=parentheses]
>>> /space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/netifd-2013-01-22.1/interface-ip.c:655:2: error: suggest parentheses around arithmetic in operand of '|' [-Werror=parentheses]
>>> cc1: all warnings being treated as errors
>> the bug here is -Werror being passed to the compiler, try adding
>> --disable-werror to the configure invocation
>>
>> (note: using -Werror by default is pretty inept, since it will cause
>> build errors on any compiler/libc combination that has not yet been
>> tested by the package author)
> 
> Normally these kind of warnings are ignored in the system headers and
> macro text expanded from macros defined in the system headers. I don't
> see any reason we can't "fix" this particular macro however if for
> some reason it's still making trouble..
> 
> Rich

I removed -Werror from CMakeLists.txt of netifd, after that it compiled (with warnings ;-) ).
Thank you!

(only size shocked me - 450KB (one day before with uClibc 50KB :-/ ))

Re: Bug in include/netinet/in.h

[Rich Felker]

On Thu, Jan 24, 2013 at 08:22:03PM +0100, Alexander Stadler wrote:
> Am 23.01.2013 18:11, schrieb Rich Felker:
> > On Wed, Jan 23, 2013 at 05:58:13PM +0100, John Spencer wrote:
> >> On 01/23/2013 05:39 PM, Alexander Stadler wrote:
> >>> [-Werror=parentheses]
> >>> /space/build-trunk/trunk/build_dir/target-mips_r2_musl-0.9.8/netifd-2013-01-22.1/interface-ip.c:655:2: error: suggest parentheses around arithmetic in operand of '|' [-Werror=parentheses]
> >>> cc1: all warnings being treated as errors
> >> the bug here is -Werror being passed to the compiler, try adding
> >> --disable-werror to the configure invocation
> >>
> >> (note: using -Werror by default is pretty inept, since it will cause
> >> build errors on any compiler/libc combination that has not yet been
> >> tested by the package author)
> > 
> > Normally these kind of warnings are ignored in the system headers and
> > macro text expanded from macros defined in the system headers. I don't
> > see any reason we can't "fix" this particular macro however if for
> > some reason it's still making trouble..
> > 
> > Rich
> 
> I removed -Werror from CMakeLists.txt of netifd, after that it compiled (with warnings ;-) ).
> Thank you!
> 
> (only size shocked me - 450KB (one day before with uClibc 50KB :-/ ))

You must have been dynamic linking with uClibc and static linking with
musl -- and linking some libs other than just libc statically, I
think, since even the whole libc is not that big.

Rich

Re: Bug in include/netinet/in.h

[John Spencer]

On 01/24/2013 08:22 PM, Alexander Stadler wrote:
>
> I removed -Werror from CMakeLists.txt of netifd, after that it compiled (with warnings ;-) ).
> Thank you!
>
> (only size shocked me - 450KB (one day before with uClibc 50KB :-/ ))
>
probably something went wrong here, usually musl-linked binaries are a 
good bit smaller than their uclibc-linked counterparts.
some guesses:
- uclibc binary is linked dynamically, but the musl one statically
- debug mode (-g) was used for the musl binary
- uclibc binary was stripped (-s) but musl one wasn't

i'd try to use strip tool on both binaries and compare
additionally comparing the used CFLAGS used by the compiler might give 
hints (compile both in verbose mode and compare build logs)
for smallest binary size, usually -flto -fwhole-program -s -Os give the 
best results with gcc >= 4.5.0 (however lto makes the build notably slower)

Re: Bug in include/netinet/in.h

[Alexander Stadler]

Am 24.01.2013 21:46, schrieb John Spencer:
> On 01/24/2013 08:22 PM, Alexander Stadler wrote:
>>
>> I removed -Werror from CMakeLists.txt of netifd, after that it compiled (with warnings ;-) ).
>> Thank you!
>>
>> (only size shocked me - 450KB (one day before with uClibc 50KB :-/ ))
>>
> probably something went wrong here, usually musl-linked binaries are a good bit smaller than their uclibc-linked counterparts.
> some guesses:
> - uclibc binary is linked dynamically, but the musl one statically
> - debug mode (-g) was used for the musl binary
> - uclibc binary was stripped (-s) but musl one wasn't
> 
> i'd try to use strip tool on both binaries and compare
> additionally comparing the used CFLAGS used by the compiler might give hints (compile both in verbose mode and compare build logs)
> for smallest binary size, usually -flto -fwhole-program -s -Os give the best results with gcc >= 4.5.0 (however lto makes the build notably slower)
> 

Thanks for the answer.
And the optimization parameters, I propably will play with them at some time.

https://dev.openwrt.org/changeset/34427
disables sstrip when musl is used,
but does not select strip instead. 
Unfortunately I don't know why sstrip got disabled.

But after enabling strip instead the size reaches comparable values (same too a bit larger most of the time).

Re: Bug in include/netinet/in.h

[Szabolcs Nagy]

* Alexander Stadler <sa.musl@univie.ac.at> [2013-01-29 18:37:54 +0100]:
> https://dev.openwrt.org/changeset/34427
> disables sstrip when musl is used,
> but does not select strip instead. 
> Unfortunately I don't know why sstrip got disabled.
> 

i've set a mail to openwrt-devel about this
in case they are not reading it here

it would be iteresting to see how well musl
works on openwrt..
are you using a real device or qemu?

Re: Bug in include/netinet/in.h

[Alexander Stadler]

Am 29.01.2013 19:10, schrieb Szabolcs Nagy:
> * Alexander Stadler <sa.musl@univie.ac.at> [2013-01-29 18:37:54 +0100]:
>> https://dev.openwrt.org/changeset/34427
>> disables sstrip when musl is used,
>> but does not select strip instead. 
>> Unfortunately I don't know why sstrip got disabled.
>>
> 
> i've set a mail to openwrt-devel about this
> in case they are not reading it here
> 
> it would be iteresting to see how well musl
> works on openwrt..
> are you using a real device or qemu?

Nbd already added the strip change :-).
I haven't compiled through by now.
All problems currently are in:
https://dev.openwrt.org/ticket/12651
(don't want to spam on the list here too much..)
Florian wrote it didn't work on qemu, so if I compile through at some time.. I decide if I want to try a real device.

Re: Bug in include/netinet/in.h

[Florian Fainelli]

Le mardi 29 janvier 2013 19:33:23, Alexander Stadler a écrit :
> Am 29.01.2013 19:10, schrieb Szabolcs Nagy:
> > * Alexander Stadler <sa.musl@univie.ac.at> [2013-01-29 18:37:54 +0100]:
> >> https://dev.openwrt.org/changeset/34427
> >> disables sstrip when musl is used,
> >> but does not select strip instead.
> >> Unfortunately I don't know why sstrip got disabled.
> > 
> > i've set a mail to openwrt-devel about this
> > in case they are not reading it here
> > 
> > it would be iteresting to see how well musl
> > works on openwrt..
> > are you using a real device or qemu?
> 
> Nbd already added the strip change :-).
> I haven't compiled through by now.
> All problems currently are in:
> https://dev.openwrt.org/ticket/12651
> (don't want to spam on the list here too much..)
> Florian wrote it didn't work on qemu, so if I compile through at some
> time.. I decide if I want to try a real device.

I tested it successfully using the OpenWrt realview target under Qemu, I had 
issues with MIPS but that was due to the fact that we disable the in-kernel 
FPU emulator.

When I did the initial qemu testing I disabled all packages that did not 
compile with musl for various reasons. Note that these targets do not have any 
of the networking packages (ppp, iptables ...) enabled by default.
-- 
Florian