uname(1) on UnixWare (Solaris)

[Bang Jun-Young]

On Wed, Jun 06, 2001 at 09:42:17AM -0700, Francois Gouget wrote:
>    I know but the only flags you check in the Linux case are one set of
> flags. You cannot assume that these are the only flags that will *ever*
> work on Linux and that these flags will *never* work on any other
> platform.
>    What if tomorrow the Linux guys say 'what we have done until now is
> really broken, we should do like the UnixWare guys'? Your script won't
> check the flags used on UnixWare if you know you are on a Linux platform
> thus it will break while the original one would have kept on working.

That will never happen, I believe. We always communicate closely with
each other, at least in the free/open source world. ;)

>    Also your uname checks cause you to duplicates the checks done on
> Linux for the FreeBSD case too.

Yes, they could be merged together.

> > Existing configure won't work, neither. We should add or modify code=20
> > in any case.
>=20
>    Yes but not by testing uname. And deriving the compile flags from
> AC_CANONICAL_HOST is not any better.
>    There is no link between `uname` and the flags to be used for
> compiling and linking. Take Solaris for instance. How do you know based
> on `uname` whether to use the native compiler flags or the gcc flags?
>    Anyway, what you want is change the NetBSD flags. What about the
> following change:

It doesn't help much because:

 * Code itself will never executed. Checking for Linux always
   succeeds on NetBSD 1.5 or later which are based on ELF.
 * NetBSD a.out support should be removed. Wine will never run on=20
   NetBSD 1.4 or earlier which lack kernel threads. They are no=20
   more actively maintained by core team.
=20
>    Now I have the following questions:
>  * we had different flags before. How come they don't work? Did the
> toolchain change on NetBSD? Should we test the old flags too in case we
> are on an old NetBSD?
>  * Don't you need flags in LDDLLFLAGS too?
>  * it seems you don't have an equivalent to '-Bsymbolic' in your flags?
> This is pretty important for Wine dlls to work correctly (they will
> compile and link without it, but run?). Is there an equivalent flag on
> NetBSD or is it simply assumed by default? hmm, maybe it's assume since
> '-Bsymbolic' is an ELF thing and NetBSD appears to be a.out based. In
> any case, to help you check if there's something similar here's what
> 'info ld' has to say about '-Bsymbolic' here:
>=20
>            When  creating  a  shared  library, bind references to
>            global symbols to the  definition  within  the  shared
>            library,  if any.  Normally, it is possible for a pro=1B)B=AD
>            gram linked against a shared library to  override  the
>            definition  within the shared library.  This option is
>            only meaningful on ELF platforms which support  shared
>            libraries.
>=20
>=20
> [...]
> > The combination works itself nicely with NetBSD, but compilation
> > doesn't. That's why I feel it's difficult to write valid test. It will
> > be easier to add "extern char **environ".
>=20
>    So it's a compilation error, not a link error. Why change the link
> flags then?

Oops, I'm sorry. It wasn't a compilation error. I got number of=20
linking errors with winetest:

perl.o(.text+0xc7f): undefined reference to `environ'
perl.o(.text+0x4077): undefined reference to `environ'
=2E..
util.o(.text+0x794): undefined reference to `environ'
=2E..

All of above object s are in lib/libperl.a.

Without -Bsymbolic, I had no problem.=20

> > What do you think about replacing "Linux dll" with "GNU style ELF dll"?
>=20
>    Could work. I guess none of the other platforms is covered by this
> description?

A new patch will be sent to wine-patches@ shortly.

Jun-Young

--=20
Bang Jun-Young <bjy at mogua.org>