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 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 NetBSD 1.4 or earlier which lack kernel threads. They are no 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)B� 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.[...]
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 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.
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 description?
A new patch will be sent to wine-patches@ shortly.
Jun-Young