uname(1) on UnixWare (Solaris)
Francois Gouget
fgouget at free.fr
Wed Jun 6 11:42:17 CDT 2001
On Wed, 6 Jun 2001, Bang Jun-Young wrote:
> 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?
Given this message and the code below can you tell me which line
printed the message?
checking whether we can build a Linux dll...
Code (based on current configure):
--- cut here ---
if test "$LIBEXT" = "so"
then
AC_CACHE_CHECK("whether we can build a `uname` dll",
...
if test "$ac_cv_c_dll_linux" = "yes"
then
...
else
AC_CACHE_CHECK(whether we can build a `uname` dll,
...
if test "$ac_cv_c_dll_unixware" = "yes"
then
...
else
AC_CACHE_CHECK("whether we can build a `uname` dll",
...
But it's obvious this is not what you intended to do so I apologize
for causing confusion.
[...]
> > > 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 ...
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.
Also your uname checks cause you to duplicates the checks done on
Linux for the FreeBSD case too.
> > 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.
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:
--- cut here ---
Index: configure.in
===================================================================
RCS file: /home/cvs/wine/wine/configure.in,v
retrieving revision 1.204
diff -u -r1.204 configure.in
--- configure.in 2001/05/31 21:35:15 1.204
+++ configure.in 2001/06/06 16:16:45
@@ -620,13 +620,13 @@
AC_CACHE_CHECK("whether we can build a NetBSD a.out dll",
ac_cv_c_dll_netbsd,
[saved_cflags=$CFLAGS
- CFLAGS="$CFLAGS -fPIC -Wl,-Bshareable,-Bforcearchive"
+ CFLAGS="$CFLAGS -fPIC -shared -Wl,-soname,conftest.so.1.0"
AC_TRY_LINK(,[return 1],ac_cv_c_dll_netbsd="yes",ac_cv_c_dll_netbsd="no")
CFLAGS=$saved_cflags
])
if test "$ac_cv_c_dll_netbsd" = "yes"
then
- LDSHARED="\$(CC) -Wl,-Bshareable,-Bforcearchive"
+ LDSHARED="\$(CC) -shared \$(SONAME:%=-Wl,-soname,%) -Wl,-rpath,\$(libdir)"
LDDLLFLAGS="" #FIXME
fi
fi
--- cut here ---
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
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?
> 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?
--
Francois Gouget fgouget at free.fr http://fgouget.free.fr/
In theory, theory and practice are the same, but in practice they're different.
More information about the wine-devel
mailing list