Re: [PATCH] Set library search path empty in dlloader-api test.

2010-06-24 Thread Charles Wilson
On 6/24/2010 7:26 PM, Peter Rosin wrote: > Zapping with the search path seems overly complicated and will > not represent anything even remotely normal. > > But all this is just my opinion of course. But I think I agree. See [PATCH] Avoid false failures caused by filesystem interaction which mig

[PATCH] Avoid false failures caused by filesystem interaction

2010-06-24 Thread Charles Wilson
* tests/dlloader-api.at (main.c:first_open): Use uglified name when "opening" pseudo-module. (main.c:last_open): Ditto. (main.c:main): Ditto. (expout): Update to reflect uglified psuedo-module names. Signed-off-by: Charles Wilson <...> --- This is an alternate solution to the problem addressed her

[PATCH] [cygwin|mingw] fix dlpreopen with --disable-static (take 7)

2010-06-24 Thread Charles Wilson
* libltdl/config/general.m4sh (func_tr_sh): New function. * libltdl/config/ltmain.m4sh (func_generate_dlsyms) [cygwin|mingw]: Obtain DLL name corresponding to import library by using value stored in unique variable libfile_$(transliterated implib name). If that fails, use $sharedlib_from_linklib_cm

Re: [PATCH] Set library search path empty in dlloader-api test.

2010-06-24 Thread Peter Rosin
Hi Chuck, Den 2010-06-25 00:50 skrev Charles Wilson: On 6/20/2010 2:31 AM, Charles Wilson wrote: Tested on cygwin, mingw, linux, and works. But, given the issues raised above...comments? discussion? Additional testing on esoteric platforms? OK to push? NOTE: From the autoconf manual: Posix

Re: lt_dlerror changes

2010-06-24 Thread Charles Wilson
On 6/17/2010 4:54 PM, Peter O'Gorman wrote: > Well, this is what I ended up with, it does not change the currently > documented saving of error messages until lt_dlerror() is called, it > copies the error message to ensure that we don't return garbage when > lt_dlerror is called. I think I also got

Re: [PATCH] Set library search path empty in dlloader-api test.

2010-06-24 Thread Charles Wilson
On 6/20/2010 2:31 AM, Charles Wilson wrote: > Tested on cygwin, mingw, linux, and works. But, given the issues > raised above...comments? discussion? Additional testing on esoteric > platforms? OK to push? > > NOTE: From the autoconf manual: > Posix prefers `setenv' to `putenv'; among other thin

Re: [PATCH] [cygwin] Refactor C++ exception handling for Win32 correctness

2010-06-24 Thread Charles Wilson
On 6/23/2010 12:47 AM, Ralf Wildenhues wrote: > * Charles Wilson wrote on Wed, Jun 23, 2010 at 06:17:41AM CEST: >> I'm going to try to get cygwin's resident gcc/binutils export, Dave K, >> to weigh in on this thread before checking anything in. Well, Dave has either been hit by a bus or he's on va

Re: MSVC: For MSVC, embed the manifest as a resource in the executable.

2010-06-24 Thread Peter Rosin
Hi Ralf, Den 2010-06-24 20:17 skrev Ralf Wildenhues: * Peter Rosin wrote on Thu, Jun 24, 2010 at 02:05:23PM CEST: Den 2010-06-23 21:02 skrev Ralf Wildenhues: This patch assumes that 'mt' is present, is what you think it is, and doesn't allow an override. On my GNU/Linux, mt is part of cpio an

Re: MSVC: For MSVC, embed the manifest as a resource in the executable.

2010-06-24 Thread Ralf Wildenhues
* Peter Rosin wrote on Thu, Jun 24, 2010 at 02:05:23PM CEST: > Den 2010-06-23 21:02 skrev Ralf Wildenhues: > >This patch assumes that 'mt' is present, is what you think it is, and > >doesn't allow an override. On my GNU/Linux, mt is part of cpio and > >controls magnetic tapes. Is there possibilit

Re: MSVC: For MSVC, embed the manifest as a resource in the executable.

2010-06-24 Thread Peter Rosin
Hi Ralf, Den 2010-06-23 21:02 skrev Ralf Wildenhues: Hi Peter, * Peter Rosin wrote on Wed, Jun 23, 2010 at 04:47:45PM CEST: "For MSVC, embed the manifest as a resource in the executable." 9f550cb81d4dfe4fc8962f23a7eccb1152e5c4a5 and the relevant part of "patch msvc-documentation.patch" 06cfc