On Tue, Jun 05, 2001 at 11:51:19PM -0700, Francois Gouget wrote:
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.
Sorry but I don't catch what you mean quite well. It's obvious which message is printed on the screen, isn't it?
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?
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 ...
No, it should be read as:
if test "$OSNAME" = "Linux" then # Check if flags work for Linux AC_CACHE_CHECK(...) if test "$ac_cv_c_dll_linux" = "yes" # Then we can safely set flags LDSHARED="..." fi elif ...
What if the flags don't work? Then we don't have to try with UnixWare or FreeBSD again. Simply you won't be able to build shared libraries on that platform and configure will give a warning.
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.
Existing configure won't work, neither. We should add or modify code in any case.
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.
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".
What do you think about replacing "Linux dll" with "GNU style ELF dll"?
Jun-Young