Dan Nicholson wrote: > Oh, we should probably be setting SHELL in configs/autoconf all the > time. Autoconf has support for this by using the shell that configure > was called with or the value of CONFIG_SHELL. > > Do you know which parts are too POSIXy? I don't think it would be too > much work to make the build work with any reasonable Bourne shell.
I don't remember off hand which part of the shell commands in the Makefile needed this - the common errors with the Solaris /bin/sh are use of things like $() instead of ``, use of [[ ]] tests instead of [ ], use of == instead of =, use of the test/[] flags listed as "Not in /bin/sh" on http://docs.sun.com/app/docs/doc/816-5165/test-1?a=view and other features invented in the almost 20 years since SVR4's bourne shell was last updated. (As Roland noted, this is being fixed in OpenSolaris by replacing /bin/sh with ksh93, and future Solaris releases may do the same, but that doesn't help users of past/current Solaris releases.) Of course, it's hard to search for $() in makefiles, since that's mostly make variable references, not shell inline command output replacement. >> +dnl OS-specific libraries >> +OS_LIBS="" >> +case "$host_os" in >> +solaris*) >> + OS_LIBS="-lc" >> + if test "x$GXX" != xyes; then >> + OS_CPLUSPLUS_LIBS="-lCrun $OS_LIBS" >> + fi >> + ;; >> +esac > > Does the linker/compiler not add these for you on solaris? Does > libtool do this for you in a fully autotooled setup? Would it be > better to add this stuff to bin/mklib? Unfortunately, the Sun compilers define the flag to build a shared library as also disabling the automatic linking of the standard C & C++ libraries. libtool has a build_libtool_need_lc variable it sets to handle this. I didn't think about adding it to bin/mklib, I suppose that would follow the libtool example. >> + solaris*) >> + DEFINES="$DEFINES -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER" >> + DEFINES="$DEFINES -DGLX_INDIRECT_RENDERING" >> + if test "x$driglx_direct" = xyes; then >> + DEFINES="$DEFINES -DGLX_DIRECT_RENDERING" >> + fi >> + ;; > > None of these settings are platform specific. I don't know why I ever > made it that way. Yeah, I just copied the other platforms there. >> @@ -914,7 +953,14 @@ dnl Only libm is added here if necess >> dnl be pulled in by the linker >> dnl >> if test "x$APP_LIB_DEPS" = x; then >> - APP_LIB_DEPS="-lm" >> + case "$host_os" in >> + solaris*) >> + APP_LIB_DEPS="-lX11 -lsocket -lnsl -lm" >> + ;; >> + *) >> + APP_LIB_DEPS="-lm" >> + ;; >> + esac >> fi > > It would be nice if we could do this in a non-platform-specific way. > Do you know why -lX11 is needed for the apps? Normally it would just > be pulled in as needed by other Mesa libraries. Are there specific > functions that libsocket and libnsl are needed for, or is it part of > using libX11? libsocket & libnsl are SysV'isms from when AT&T allowed Berkeley sockets to be merged in, but not put into libc, since the TLI API was clearly superior and going to replace it (you see how well that worked out). The autoconf checks we use in X.Org's xtrans.m4 for these are: # SVR4 hides these in libraries other than libc AC_SEARCH_LIBS(socket, [socket]) AC_SEARCH_LIBS(gethostbyname, [nsl]) As for libX11, the Solaris linker complains if you call an X11 function like XOpenDisplay() from your application, but don't link directly to it, even if you link to something like libGL that links to it (it assumes that dependencies of other libraries could change and you're safer to declare what you need and not just hope libGL always uses libX11 and never drops it for libxcb). -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Mesa3d-dev mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
