http://bugs.winehq.org/show_bug.cgi?id=20714
Summary: build fails on OpenSolaris: ifenum.c:322: error: structure has no member named `ifr_hwaddr' Product: Wine Version: 1.1.33 Platform: PC OS/Version: Solaris Status: UNCONFIRMED Severity: normal Priority: P3 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: christian.thalinger@gmail.com
The build fails because SIOCGIFHWADDR is defined but the ifreq structure does not have a ifr_hwaddr field.
make[2]: Entering directory `/export/home/twisti/projects/wine/wine-1.1.33/dlls/iphlpapi' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing -Wdeclaration-after-statement -Wstrict-prototypes -Wwrite-strings -Wpointer-arith -g -O2 -o ifenum.o ifenum.c ifenum.c: In function `getInterfacePhysicalByName': ifenum.c:322: error: structure has no member named `ifr_hwaddr' ifenum.c:367: error: structure has no member named `ifr_hwaddr' ifenum.c:367: error: structure has no member named `ifr_hwaddr' ifenum.c:376: error: structure has no member named `ifr_hwaddr' make[2]: *** [ifenum.o] Error 1
twisti@macbook:~/projects/wine/wine-1.1.33$ ack HAVE_SYS_SOCKIO_H include/config.h #define HAVE_SYS_SOCKIO_H 1
twisti@macbook:~/projects/wine/wine-1.1.33$ ack SIOCGIFHWADDR /usr/include/ /usr/include/sys/sockio.h 313:#define SIOCGIFHWADDR _IOWR('i', 185, int) /* PF_PACKET */
http://bugs.winehq.org/show_bug.cgi?id=20714
Vitaliy Margolen vitaliy@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |blocker
http://bugs.winehq.org/show_bug.cgi?id=20714
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source
http://bugs.winehq.org/show_bug.cgi?id=20714
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
http://bugs.winehq.org/show_bug.cgi?id=20714
Petr Sumbera petr.sumbera@sun.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |petr.sumbera@sun.com
--- Comment #1 from Petr Sumbera petr.sumbera@sun.com 2009-11-19 09:28:50 --- Since OpenSolaris build 125, SIOCGIFHWADDR is now supported on (and only on) PF_PACKET sockets.
See: http://arc.opensolaris.org/caselog/PSARC/2009/232/pfp-psarc.txt
Two new interfaces need to be added, SIOCGIFHWADDR and SIOCGSTAMP. SIOCGIFHWADDR retrieves the hardware inteface of the interface specified in the "struct ifreq" passed in. SIOCGSTAMP .... At present there are no plans for a SIOCGLIFHWADDR as this ioctl does not exist on Linux. This project will only support these two ioctls on PF_PACKET sockets.
Similar problem was also encountered in KDE: http://opensolaris.org/jive/thread.jspa?messageID=428636
Following or similar patch need to be added:
--- a/dlls/iphlpapi/ifenum.c +++ b/dlls/iphlpapi/ifenum.c @@ -298,7 +298,7 @@ static DWORD getInterfaceMaskByName(const char *name) return ret; }
-#if defined (SIOCGIFHWADDR) +#if defined (SIOCGIFHWADDR) && !defined(__sun) static DWORD getInterfacePhysicalByName(const char *name, PDWORD len, PBYTE addr, PDWORD type) {
http://bugs.winehq.org/show_bug.cgi?id=20714
richard.palo@baou.fr changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #2 from richard.palo@baou.fr 2009-12-05 11:29:18 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=20714
Matt Lewandowsky matt@greenviolet.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |matt@greenviolet.net
http://bugs.winehq.org/show_bug.cgi?id=20714
Maurizio Oliveri 6tsukiyami9@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |6tsukiyami9@gmail.com
--- Comment #3 from Maurizio Oliveri 6tsukiyami9@gmail.com 2010-02-19 15:00:58 --- Still happens up to wine .39 so far
http://bugs.winehq.org/show_bug.cgi?id=20714
Jase Whipp jason.whipp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jason.whipp@gmail.com
--- Comment #4 from Jase Whipp jason.whipp@gmail.com 2010-03-12 12:10:38 --- Just tested with 1.1.40, still happening.
ifenum.c: In function `getInterfacePhysicalByName': ifenum.c:322: error: structure has no member named `ifr_hwaddr' ifenum.c:367: error: structure has no member named `ifr_hwaddr' ifenum.c:367: error: structure has no member named `ifr_hwaddr' ifenum.c:376: error: structure has no member named `ifr_hwaddr' make[1]: *** [ifenum.o] Error 1 make[1]: Leaving directory `/home/jwhipp/wine-1.1.40/dlls/iphlpapi' make: *** [dlls/iphlpapi] Error 2
Applied the patch described in comment #2 which fixed the problem.
http://bugs.winehq.org/show_bug.cgi?id=20714
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
--- Comment #5 from Austin English austinenglish@gmail.com 2010-03-12 12:11:49 --- Please submit patches to wine-patches@winehq.org
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #6 from Juan Lang juan_lang@yahoo.com 2010-03-12 12:42:20 --- Created an attachment (id=26765) --> (http://bugs.winehq.org/attachment.cgi?id=26765) Patch: Check for ifr_hwaddr member of struct ifreq
Does this patch help? You'll need to apply it, then run autoconf, followed by configure, before building.
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #7 from Maurizio Oliveri 6tsukiyami9@gmail.com 2010-03-12 13:34:14 --- Created an attachment (id=26769) --> (http://bugs.winehq.org/attachment.cgi?id=26769) SFE wine's patch
wine patch for opensolaris, SIOCGIFHWADDR
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #8 from Maurizio Oliveri 6tsukiyami9@gmail.com 2010-03-12 13:36:39 --- wine patch for opensolaris, SIOCGIFHWADDR problem have been fixed by SFE: a few days ago they updated wine's spec file, and now it compiles flawlessy. Too bad, the programs I've tried running with version from .33 up give some opengl-related errors and are unusable...
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #9 from Austin English austinenglish@gmail.com 2010-03-12 14:29:03 --- (In reply to comment #8)
wine patch for opensolaris, SIOCGIFHWADDR problem have been fixed by SFE: a few days ago they updated wine's spec file, and now it compiles flawlessy.
Wine should still be fixed, not everyone compiles from SFE...besides, other platforms (NetBSD), has a similar bug that this may help.
Too bad, the programs I've tried running with version from .33 up give some opengl-related errors and are unusable...
If it worked in previous versions, run a regression test and file a new bug: http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #10 from Jase Whipp jason.whipp@gmail.com 2010-03-12 15:09:00 --- SFEwine also has SFE based dependencies many of which are already supplied with OSOL packages.
After applying the patch listing in this bug, the compile completed and wine runs. I still don't have sound support but that's another issue.
-Jase
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #11 from Juan Lang juan_lang@yahoo.com 2010-03-12 17:37:40 --- (In reply to comment #10)
After applying the patch listing in this bug, the compile completed and wine runs.
Which patch do you mean? There are patches in comments 1, 6, and 7 :p
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #12 from Maurizio Oliveri 6tsukiyami9@gmail.com 2010-03-12 19:31:52 ---
If it worked in previous versions, run a regression test and file a new bug: http://wiki.winehq.org/RegressionTesting
Just did: http://bugs.winehq.org/show_bug.cgi?id=22023 Thanks for linking that tutorial, by the way!
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #13 from Matt Lewandowsky matt@greenviolet.net 2010-03-12 19:39:50 --- Note that the SFE patch just reverses the order of the tests to get a working compilation; it's the same net effect as the patch in comment #1 and broken in different ways. (Broken for the purposes of cross-platform compilation; they both work just fine on the OS in question.)
The real solution is to probably rewrite that whole section of ifenum.c, but I don't have the time allocated to look into doing so myself.
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #14 from Juan Lang juan_lang@yahoo.com 2010-03-12 21:23:43 --- (In reply to comment #13)
The real solution is to probably rewrite that whole section of ifenum.c, but I don't have the time allocated to look into doing so myself.
The patch I uploaded does this in a cleaner way, in that it relies on configure checks to determine whether the feature is present before attempting to use it. That makes it a little less prone to breaking due to accidental effects such as order. Could someone please try it and report back?
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #15 from Matt Lewandowsky matt@greenviolet.net 2010-03-12 21:33:10 --- (In reply to comment #14)
That doesn't seem to fix the issue where the whole set of tests in ifenum.c appears faulty. All the patches so far just bandage around the current breakage, ignoring the underlying faults.
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #16 from Jase Whipp jason.whipp@gmail.com 2010-03-12 21:41:24 --- I applied the patch in comment #1 from Petr Sumbera.
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #17 from Juan Lang juan_lang@yahoo.com 2010-03-12 22:23:33 --- (In reply to comment #15)
That doesn't seem to fix the issue where the whole set of tests in ifenum.c appears faulty. All the patches so far just bandage around the current breakage, ignoring the underlying faults.
This isn't very constructive. Explain what you think should happen, and what your rationale is.
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #18 from Juan Lang juan_lang@yahoo.com 2010-03-12 22:28:59 --- (In reply to comment #16)
I applied the patch in comment #1 from Petr Sumbera.
Thanks. That one's unlikely to make it in, because in general we try to avoid platform specific conditional compilation like this, preferring to test for the presence or absence of specific features instead. I'd appreciate it if you (or someone else) would try the patch I submitted.
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #19 from Austin English austinenglish@gmail.com 2010-03-12 23:08:36 --- (In reply to comment #18)
(In reply to comment #16)
I applied the patch in comment #1 from Petr Sumbera.
Thanks. That one's unlikely to make it in, because in general we try to avoid platform specific conditional compilation like this, preferring to test for the presence or absence of specific features instead. I'd appreciate it if you (or someone else) would try the patch I submitted.
Works fine for me in 1.1.40. Thanks Juan!
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #20 from Matt Lewandowsky matt@greenviolet.net 2010-03-12 23:10:24 --- (In reply to comment #17)
I know it's not very constructive, which is why I didn't chime in earlier. I don't yet really know what it should do, else I would have attached an initial patch here (aside from my patch in SFE which got attached by someone else). But, the current code looks too "organic".
Also, what's wrong with using SIOCGARP on Linux? I am not in a Linux VM at the moment, but is the Stevens code broken on Linux somehow? (See "Unix Network Programming, Volume 1".)
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #21 from Juan Lang juan_lang@yahoo.com 2010-03-13 11:47:30 --- (In reply to comment #20)
But, the current code looks too "organic".
It also works (with the patch) on a number of systems, and that generally is worth a lot.
Also, what's wrong with using SIOCGARP on Linux?
Don't know, but that's not the point of this bug. If you don't like it, patch away.
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #22 from Matt Lewandowsky matt@greenviolet.net 2010-03-14 20:09:18 --- (In reply to comment #21)
Also, what's wrong with using SIOCGARP on Linux?
Don't know, but that's not the point of this bug. If you don't like it, patch away.
Well, it kinda is... After all, if SIOCGARP can be used on Linux, there's no need for SIOCGIFHWADDR there, either, for getting the MAC address. And I am 99.999% positive that BSD still supports getting the MAC address via SIOCGARP too. Being well documented by Stevens, it's probably the best choice of least-common-denominator. Then one could work around its absence on specific systems.
The benefit? Simpler code, consistent behavior cross-platform (as they'd all be using the same interface), and I'm pretty sure lots of people use Stevens's approach, as it's been around at least 20 years. So you get the benefit of consistency with other codebases in other projects.
I have a copy of UNP 3rd Edition lying around here, so I'll be able to compare Wine's SIOCGARP stuff against it. I'll add it to tomorrow's todo list to investigate ifenum.c and see about patching it up to be simpler and more cross-platform with fewer special cases.
http://bugs.winehq.org/show_bug.cgi?id=20714
--- Comment #23 from Juan Lang juan_lang@yahoo.com 2010-03-14 21:09:58 --- (In reply to comment #22)
Don't know, but that's not the point of this bug.
Well, it kinda is...
Not really, this is about a specific compile failure. I sent a fix for that. "Cleaner approach" == a different bug.
After all, if SIOCGARP can be used on Linux, there's no need for SIOCGIFHWADDR there, either, for getting the MAC address. And I am 99.999% positive that BSD still supports getting the MAC address via SIOCGARP too. Being well documented by Stevens, it's probably the best choice of least-common-denominator. Then one could work around its absence on specific systems.
Yep. Onus is on you to test it though. When I wrote this code (7 years ago!) I tested it on Solaris, MacOS X server, and various Linuxen. I no longer recall if SIOCGIFHWADDR was needed to cover all the Linux boxes I tried it on, but even it had been, things may have changed.
The benefit? Simpler code, consistent behavior cross-platform (as they'd all be using the same interface), and I'm pretty sure lots of people use Stevens's approach, as it's been around at least 20 years.
Pretty sure ain't the same as tested. I know at least one system (FreeBSD) that doesn't support SIOCGARP. But, I'm following you off topic. Different forum, please.
http://bugs.winehq.org/show_bug.cgi?id=20714
Juan Lang juan_lang@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #24 from Juan Lang juan_lang@yahoo.com 2010-03-15 12:29:34 --- Fixed by commit 984c3b2ccb83655209b969296e311b36fcf836be.
http://bugs.winehq.org/show_bug.cgi?id=20714
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #25 from Alexandre Julliard julliard@winehq.org 2010-03-19 14:10:44 --- Closing bugs fixed in 1.1.41.