Bug 1124368 - mingw32-crt has wrong value for in6addr_loopback
Summary: mingw32-crt has wrong value for in6addr_loopback
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora EPEL
Classification: Fedora
Component: mingw-crt
Version: epel7
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Erik van Pienbroek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-29 11:05 UTC by Chris Paulson-Ellis
Modified: 2014-08-04 12:40 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-08-04 12:40:26 UTC


Attachments (Terms of Use)

Description Chris Paulson-Ellis 2014-07-29 11:05:23 UTC
The value of _in6addr_loopback is wrong. It should be ::1, but is :: (all zeros). See the "Contents of section .rdata" in the objdump snippet below...

$ rpm -q -f /usr/i686-w64-mingw32/sys-root/mingw/lib/libws2_32.a
mingw32-crt-3.1.999-0.10.trunk.gitb8e816.20140530.el7.noarch

$ i686-w64-mingw32-objdump -x -s /usr/i686-w64-mingw32/sys-root/mingw/lib/libws2_32.a
[snip]
SYMBOL TABLE:
[  0](sec  1)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00000000 .text
AUX scnlen 0x0 nreloc 0 nlnno 0
[  2](sec  2)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00000000 .data
AUX scnlen 0x0 nreloc 0 nlnno 0
[  4](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00000000 .bss
AUX scnlen 0x0 nreloc 0 nlnno 0
[  6](sec  4)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00000000 .rdata
AUX scnlen 0x20 nreloc 0 nlnno 0
[  8](sec  5)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00000000 .rdata$zzz
AUX scnlen 0x35 nreloc 0 nlnno 0
[ 10](sec  4)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000000 _in6addr_loopback
[ 11](sec  4)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000010 _in6addr_any


Contents of section .rdata:
 0000 00000000 00000000 00000000 00000000  ................
 0010 00000000 00000000 00000000 00000000  ................
Contents of section .rdata$zzz:
 0000 4743433a 2028474e 55292034 2e392e30  GCC: (GNU) 4.9.0
 0010 20323031 34303432 32202846 65646f72   20140422 (Fedor
 0020 61204d69 6e475720 342e392e 302d312e  a MinGW 4.9.0-1.
 0030 656c3729 00000000                    el7)....        
[snip]


This is what it should look like - from Fedora 20...

$ rpm -q -f /usr/i686-w64-mingw32/sys-root/mingw/lib/libws2_32.a
mingw32-crt-3.1.0-3.fc20.noarch

$ i686-w64-mingw32-objdump -x -s /usr/i686-w64-mingw32/sys-root/mingw/lib/libws2_32.a
[snip]
SYMBOL TABLE:
[  0](sec  1)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00000000 .text
AUX scnlen 0x0 nreloc 0 nlnno 0
[  2](sec  2)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00000000 .data
AUX scnlen 0x0 nreloc 0 nlnno 0
[  4](sec  3)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00000000 .bss
AUX scnlen 0x0 nreloc 0 nlnno 0
[  6](sec  4)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00000000 .rdata
AUX scnlen 0x20 nreloc 0 nlnno 0
[  8](sec  5)(fl 0x00)(ty   0)(scl   3) (nx 1) 0x00000000 .rdata$zzz
AUX scnlen 0x36 nreloc 0 nlnno 0
[ 10](sec  4)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000000 _in6addr_loopback
[ 11](sec  4)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x00000010 _in6addr_any


Contents of section .rdata:
 0000 00000000 00000000 00000000 00000001  ................
 0010 00000000 00000000 00000000 00000000  ................
Contents of section .rdata$zzz:
 0000 4743433a 2028474e 55292034 2e382e32  GCC: (GNU) 4.8.2
 0010 20323031 33313031 36202846 65646f72   20131016 (Fedor
 0020 61204d69 6e475720 342e382e 322d312e  a MinGW 4.8.2-1.
 0030 66633230 29000000                    fc20)...        
[snip]

I've logged this issue under mimgw32-w32api because there is no mingw32-crt component.

Regards,
Chris.

Comment 1 Richard W.M. Jones 2014-07-29 11:07:59 UTC
Adding Kai as I guess this is an upstream bug.

Comment 2 Erik van Pienbroek 2014-07-29 19:01:24 UTC
Reassigning to the component mingw-crt.

This seems to be a side effect for a related issue which I fixed upstream recently for bug 1067426

In mingw-crt (mingw-w64-crt/libsrc/ws2_32.c) currently this piece of code is used:
  const struct in6_addr in6addr_loopback = {{ IN6ADDR_LOOPBACK_INIT }};

My first guess is that the braces need to be removed. In the upstream fix I mentioned this define is used:

#define IN6ADDR_LOOPBACK_INIT { { { 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1 } } }

(previously there were no braces here).


This needs more testing to be certain..

Comment 3 Erik van Pienbroek 2014-07-29 20:01:53 UTC
Could you check if http://koji.fedoraproject.org/koji/taskinfo?taskID=7211028 resolves the issue for you?

Comment 4 Chris Paulson-Ellis 2014-07-30 09:55:34 UTC
(In reply to Erik van Pienbroek from comment #3)
> Could you check if
> http://koji.fedoraproject.org/koji/taskinfo?taskID=7211028 resolves the
> issue for you?

It does. Thanks.
Chris.

Comment 5 Erik van Pienbroek 2014-07-30 19:34:56 UTC
The fix was just proposed and accepted upstream: https://sourceforge.net/p/mingw-w64/mingw-w64/ci/88ab6fbdd0a185702a1fce4db935e303030e082f/

I'm going to prepare a mingw-w64 toolchain update which includes this fix and various other ones and once they pass a mass-rebuild test (which takes roughly a day to complete) I'm going to push the updated packages to epel7

Comment 6 Erik van Pienbroek 2014-08-04 12:40:26 UTC
Fix was pushed to epel7 with mingw-crt-3.1.999-0.12.trunk.gitec1ff7.20140730.el7


Note You need to log in before you can comment on or make changes to this bug.