Re: cygwin dlopening backends

Ralf Wildenhues wrote: First, let me thank you for your insightful and very nicely written mail; the thread pointers are very helpful -- it took a while to read through them all. There are several separate issues here: 1) lt_dlhandle_iterate breakage of loadlibrary.c 2) needed dlinterface_free

Nit in func_win32_libid (branch-1.5)

This has been bugging me since we last looked at this piece of code (2005-09-25) and we didn't take the opportunity to fix it then. Should be obvious...also "needed" in ltmain.m4sh of HEAD. 2005-11-09 Charles Wilson <[EMAIL PROTECTED]> * ltmain.in (func_win32_libid): use $SED not sed

Re: SCO/bugfix patch 7 of 10: Improve SCO platform support

On Wed, 9 Nov 2005, Ralf Wildenhues wrote: Hi Ralf, > > * Tim Rice wrote on Wed, Nov 09, 2005 at 06:57:16AM CET: > > I don't know if this is any help or not, but here are the > > before and after stats on the (sco) platforms I have running. > > http://www.multitalents.net/branch-1-5-status.html >

Re: Sync C++ linking on HEAD with branch-1-5

On Wed, Nov 09, 2005 at 08:23:05PM -0600, Albert Chin wrote: > On Wed, Nov 09, 2005 at 09:51:12PM +0100, Ralf Wildenhues wrote: > > * Albert Chin wrote on Wed, Nov 09, 2005 at 05:11:09PM CET: > > It's hpux10*|hpux11*, and hppa*64*|ia64*, and aCC|g++, right? > > I can vouch for it on hpux11*, hppa*

Re: Sync C++ linking on HEAD with branch-1-5

On Wed, Nov 09, 2005 at 09:51:12PM +0100, Ralf Wildenhues wrote: > * Albert Chin wrote on Wed, Nov 09, 2005 at 05:11:09PM CET: > > When linking C++ libraries/programs, link with the compiler, not the > > linker. Syncs with branch-1-5. > > Erm, I can't see this in branch-1-5. Oops. My fault. It is

Re: CONFIG_SHELL and `./config.status --recheck'

That patch looks good to me, except: > + CONFIG_SHELL=$SHELL exec $SHELL $[0] $ac_configure_args > \$ac_configure_extra_args --no-create --no-recursion Many shells treat "A=B exec COMMAND" differently; they ignore the assignment. For example, ksh M-11/16/88i, or Solaris 10 /bin/sh. I suspect t

Re: uninitialized variables

* Ralf Wildenhues wrote on Sun, Nov 06, 2005 at 10:46:28PM CET: > > A bit more fallout. OK to apply to branch-1-5 and forward-port? > > - unset is not portable. Should I rather set lt_unset somewhere > in the initialization code and use that instead? > - the ld_shlibs_F77 test expands before

FYI: Fix variables_saved_for_relink

* Ralf Wildenhues wrote on Sun, Nov 06, 2005 at 07:40:19PM CET: > > OK to apply to branch-1-5 and forward-port? Applied to branch-1-5 and HEAD, the forward-port is below. Cheers, Ralf * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS): Move setting of `variables_saved_for_relink'..

FYI: branch-1-5: static flag check

* Ralf Wildenhues wrote on Sun, Nov 06, 2005 at 07:39:15PM CET: > > * libtool.m4 (AC_LIBTOOL_LANG_C_CONFIG): Move static_flag > check.. > (AC_LIBTOOL_PROG_COMPILER_PIC): ..here, so that both > `lt_prog_compiler_static' have actually been set, and the check >

FYI: (non)recursive mode fixups

Hi Gary, * Gary V. Vaughan wrote on Mon, Nov 07, 2005 at 04:55:16PM CET: > Ralf Wildenhues wrote: > > > >First the good thing: in principle, libltdl can do fine without an > >AC_CONFIG_HEADER at all: *snip* > > Sweet! Along with a patch to libtool.texi that explains to the user > how to make sur

Re: CONFIG_SHELL and `./config.status --recheck'

Hi Paul, * Paul Eggert wrote on Mon, Nov 07, 2005 at 03:11:26AM CET: > Ralf Wildenhues <[EMAIL PROTECTED]> writes: > > > One possibility would be to restart once with /bin/sh, or, if part of > > the environment, with CONFIG_SHELL, or, after parsing the command line, > > with CONFIG_SHELL, if that

Re: Sync C++ linking on HEAD with branch-1-5

Hi Albert, * Albert Chin wrote on Wed, Nov 09, 2005 at 05:11:09PM CET: > When linking C++ libraries/programs, link with the compiler, not the > linker. Syncs with branch-1-5. Erm, I can't see this in branch-1-5. It's hpux10*|hpux11*, and hppa*64*|ia64*, and aCC|g++, right? Does something fail wi

Sync C++ linking on HEAD with branch-1-5

When linking C++ libraries/programs, link with the compiler, not the linker. Syncs with branch-1-5. -- albert chin ([EMAIL PROTECTED]) -- snip snip 2005-11-09 Albert Chin-A-Young <[EMAIL PROTECTED]> * libltdl/m4/libtool.m4 (_LT_LANG_CXX_CONFIG): Sync C++ linking on HP-UX with b

Re: SCO/bugfix patch 7 of 10: Improve SCO platform support

Well, I believe the SCOABSPATH is not only ugly, but also broken (from a libtool perspective): if you have a package which creates two libraries, one depending on the other, your uninstalled library will link against a previous installed version, if that exists. While testing, this is wrong. I a

Re: SCO/bugfix patch 7 of 10: Improve SCO platform support

I believe hardcode_libdir_flag_spec should be set to '${wl}-R,$libdir' in any case. This has little to do with absolute sonames, but with the dependent programs finding the library. So the SCOABSPATH hack is mixing up different issues here. Not at all. If you are using absolute path names yo

Re: SCO/bugfix patch 7 of 10: Improve SCO platform support

* Ralf Wildenhues wrote on Wed, Nov 09, 2005 at 08:55:15AM CET: > > So, I ask you or Kean to resubmit the patch without the SCOABSPATH > parts, then I'll take another look again with the help of the manpages > you pointed to. Forgot one thing, sorry: | + _LT_AC_TAGVAR(hardcode_libdir_flag_spec,

Re: SCO/bugfix patch 7 of 10: Improve SCO platform support

Hi Tim, * Tim Rice wrote on Wed, Nov 09, 2005 at 06:57:16AM CET: > On Tue, 1 Nov 2005, Ralf Wildenhues wrote: > > * Kean Johnston wrote on Mon, Oct 31, 2005 at 06:43:03PM CET: > > > >Patch 7 of 10 attached ... > > > > > > Here's a re-submission using install_libdir instead of the > > > 'instrpath