uname(1) on UnixWare (Solaris)
bjy at mogua.org
Wed Jun 6 13:05:00 CDT 2001
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
> 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.
> 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.
> 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:
> 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
> > 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".
> 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'
util.o(.text+0x794): undefined reference to `environ'
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"?
> Could work. I guess none of the other platforms is covered by this
A new patch will be sent to wine-patches@ shortly.
Bang Jun-Young <bjy at mogua.org>
More information about the wine-devel