uname(1) on UnixWare (Solaris)

[Francois Gouget]

On Wed, 6 Jun 2001, Bang Jun-Young wrote:

> On Tue, Jun 05, 2001 at 12:18:00AM -0700, Francois Gouget wrote:
> > On Tue, 5 Jun 2001, Bang Jun-Young wrote:
> > > 1. Configure message is wrong:
> > >    checking whether we can build a Linux dll... yes
> > >    I see this even on FreeBSD and NetBSD. :( It's not a Linux dll, 
> > >    but an FreeBSD/NetBSD dll.
> > 
> >    Maybe this message should be changed, yes. But I don't think you
> > should put a `uname` there.
> 
> Could you explain me a bit further why we shouldn't do that?

   Maybe it was not your intention but I was afraid that we would end up
with something like:
     "checking whether we can build a `uname` dll..."
   and then a few lines down:
     "checking whether we can build a `uname` dll..."

   The problem is then you don't know exactly where the message comes
from.


[...]
> programs/winetest.c couldn't find where the global variable environ
> is. It could be easily fixed by adding 'extern char **environ' to the 
> beginning of the file without touching ld flags, but I thought it
> would be better if I was able to do the same without touching sources
> instead.

   It sounds like a compilation error. One that I've seen in a few
Winelib programs by the way. The problem is that the Unix C library
headers are not entirely compatible with the windows ones. The solution
is to use the msvcrt headers, i.e. Wine's microsoft compatible C library
headers, and import msvcrt.dll in the '.spec' file too. In winetest I
see:
    envp = environ;  /* envp is not valid (yet) in Winelib */
   Maybe envp is valid now. If not then it should be fixed and environ
removed.

   Anyway, if it's a compilation error I don't understand why you would
need to change the ld flags and how it could help. Are you getting a
link error? What does it say?


> > > 3. IMHO, my modification is more readable than existing code. 
> > 
> >    Why don't you show us the new code, or an outline thereof?
> 
> Oh, I'm sorry to forget that. *) Here it is. 

   Here's the problem. Your patch essentially does the following:

  OSNAME=`uname`
  if test "$OSNAME" = "Linux"
  then
     # Set flags for Linux
  elif test "$OSNAME" = "FreeBSD"
  then
    # Set flags for FreeBSD
  elif test "$OSNAME" = "UnixWare"
  then
    # Set flags for UnixWare
  elif ...

   But what if one runs this configure script on Darwin. The configure
script does not know about it so it will fail although Darwin might
behave exactly like FreeBSD. And what if tomorrow the Linux toolchain
changes to behave like UnixWare, or something entirely different? This
configure script will not work anymore, and when you detect that
'OSNAME==Linux' you'll still have to determine whether to use the old or
the new flags somehow.
   This is the whole point of Autoconf-style scripts: it's pointless to
expect to guess how things work based on the name of the platform, i.e
what uname returns.
   Instead you should test features: if I compile&link a test file with
the '-shared -Wl,-Bsymbolic' flag combination does it work? If yes then
it does not matter whether the platform is Linux, UnixWare or FeeeBSD.
We'll just use these flags since they do what we want.


--
Francois Gouget         fgouget at free.fr        http://fgouget.free.fr/
            "Lotto: A tax on people who are bad at math." -- unknown
          "Windows: Microsoft's tax on computer illiterates." -- WE7U