tools/wrc/wrc.c portability breakage

[Gerald Pfeifer]

The following patch broke portability of tools/wrc/wrc.c:

revision 1.18
  date: 2002/12/06 19:49:36;  author: julliard;  state: Exp;  lines: +78 -10
  Dimitrie O. Paun 
  Make wrc command line compatible with windres.

1) getopt() is supposed to to come from <unistd.h>, and <getopt.h> is
a non-standard header.

2) getopt_long() is non-portable (and does not exist on FreeBSD, for
example).

The man page for getopt() clearly shows that, BTW:

#define _GNU_SOURCE
   #include <getopt.h>

Would you mind fixing this problem?

Thanks,
Gerald

[Dimitrie O. Paun]

On December 7, 2002 05:48 am, Gerald Pfeifer wrote:
> - getopt_long() is non-portable (and does not exist on FreeBSD, for
>
> example).

Sorry, but I don't have *BSD, and I have no idea how you parse long
options on BSD. If you tell me, I'd be happy to oblige.

[Gerald Pfeifer]

On Sat, 7 Dec 2002, Dimitrie O. Paun wrote:
> > - getopt_long() is non-portable (and does not exist on FreeBSD, for
> >
> > example).
>
> Sorry, but I don't have *BSD, and I have no idea how you parse long
> options on BSD. If you tell me, I'd be happy to oblige.

It's the other way around: Not *BSD needs a special treatment, but
getopt_long() only exists on GNU systems (it depends on GNU, not the
Linux kernel), nowhere else.

A short time fix would be to
 1) detect the presence of the getopt.h header using autoconf and only
    #include that header if it exists, and
 2) use getopt_long() only in this case and just use getopt(), else.

(Yes, this reduces functionality on non-GNU systems, but basically it
they still will work.)

Alternately, the getopt package needs to become a part of Wine, i.e.,
imported into Wine CVS.

Gerald

[Dimitrie O. Paun]

On December 7, 2002 11:12 am, Gerald Pfeifer wrote:
> It's the other way around: Not *BSD needs a special treatment, but
> getopt_long() only exists on GNU systems (it depends on GNU, not the
> Linux kernel), nowhere else.

It's all a matter of perspective: if you count by the percentage of
system types that have getopt_long, you are correct, but if you count
by the number of installed systems the situation is reversed.

Nevertheless, I will fix this for you. But I would like to note that
an actual patch to fix this problem from the people that care about it
would help a lot more than complaining about it. The fix is fairly 
simple (implement getopt_long in port.[hc], either by degrading to
getopt, or by copying the getopt_long implementation from glibc, which
now has a compatible license), and it's so much easier to test its
correction on the actual problematic system.

[Gerald Pfeifer]

On Sat, 7 Dec 2002, Dimitrie O. Paun wrote:
> Nevertheless, I will fix this for you.

Thanks a lot!
> But I would like to note that an actual patch to fix this problem from
> the people that care about it would help a lot more than complaining
> about it.

Usually I'd do that (and I've done it a couple of dozen times in the
past); just this week it's not feasible for me, so I took the second
best route. ;-)

Thanks again,
Gerald