Hi Chuck,
[Warning: thread hijack - please start a new thread and paste in any context
you need if you care to reply further.]
On 25 Jun 2010, at 06:23, Charles Wilson wrote:
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
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
Den 2010-06-18 07:21 skrev Peter O'Gorman:
On 06/17/2010 10:35 PM, Peter O'Gorman wrote:
On 06/17/2010 10:21 PM, Charles Wilson wrote:
On 6/17/2010 10:24 PM, Peter O'Gorman wrote:
Unfortunately, this doesn't magically assist solving my problem with
71. dlloader-api.at:23: FAILED
On 6/18/2010 6:42 AM, Peter Rosin wrote:
That error could just as well come from the last_open function.
I've got this nagging feeling that something clobbers the module
name before it reaches the last_open function and that it's
that clobbering that is the cause of the failure. Not time to
On 06/18/2010 08:09 AM, Charles Wilson wrote:
Here's the key bit:
Searching for preloaded symbol table for last
vs
Searching for preloaded symbol table for /usr/bin/last
SO, before preopen:vmopen is called, somebody -- one of the other
loaders? -- modified 'filename' simply because
On 06/18/2010 08:36 AM, Peter O'Gorman wrote:
On 06/18/2010 08:33 AM, Peter O'Gorman wrote:
On 06/18/2010 08:09 AM, Charles Wilson wrote:
Here's the key bit:
Searching for preloaded symbol table for last
vs
Searching for preloaded symbol table for /usr/bin/last
SO, before preopen:vmopen is
On 6/18/2010 10:50 AM, Charles Wilson wrote:
although oddly, loadlibrary sets CANNOT_OPEN instead of FILE_NOT_FOUND
(loadlibary.c:vmopen):
232 if (!module)
233 LOADLIB_SETERROR (CANNOT_OPEN);
234 else if (cur)
235 {
236 LT__SETERROR (CANNOT_OPEN);
On 6/18/2010 9:36 AM, Peter O'Gorman wrote:
On 06/18/2010 08:33 AM, Peter O'Gorman wrote:
Yes, the preopen loader gets tried first with last.a, it failed, then
find_handle is called which does an access() check for last in every dir
in path,
Correction for lack of coffee: not PATH, but
On 6/18/2010 10:27 AM, Peter O'Gorman wrote:
This should (hopefully) stop the preopen loader getting used twice,
It does, and I think this is the right thing to do here. But...
and
perhaps (I'm really dreaming now) give a better error.
Nope, doesn't help this issue.
But I think clobbering
On Fri, 18 Jun 2010, Charles Wilson wrote:
The final loader called, for /usr/bin/last -- which exists -- is the
'last' loader. In last_open(), it sets LT_ERROR_FILE_NOT_FOUND as a
sort of generic error value -- which, strangely, is exactly the
OPPOSITE of the problem here.
The real problem is
On 6/18/2010 2:32 PM, Bob Friesenhahn wrote:
The real problem is there actually IS a file named /usr/bin/last, but
because that name does not match exactly last, last_open() reports
what it considers a generic error.
I seem to be backlogged by the flurry of email, but hopefully you guys
On Fri, 18 Jun 2010, Charles Wilson wrote:
If so, this raises security implications
that we want to avoid.
I don't think so.
Hopefully not. If a binary from an executable program is placed at
the path C:\cygwin\bin\last (with no .exe extension) does
LoadLibrary() load it?
Since we are
On 6/18/2010 2:52 PM, Bob Friesenhahn wrote:
On Fri, 18 Jun 2010, Charles Wilson wrote:
If so, this raises security implications
that we want to avoid.
I don't think so.
Hopefully not. If a binary from an executable program is placed at the
path C:\cygwin\bin\last (with no .exe
Hi,
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 all the places where we were
setting
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
On 06/17/2010 08:36 PM, Charles Wilson wrote:
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
On 6/17/2010 10:24 PM, Peter O'Gorman wrote:
Unfortunately, this doesn't magically assist solving my problem with
71. dlloader-api.at:23: FAILED (dlloader-api.at:422)
but that's not a reason to object to the patch.
Well that sucks :(
I suggest changing the LT__SETERROR macro in
On 06/17/2010 10:21 PM, Charles Wilson wrote:
On 6/17/2010 10:24 PM, Peter O'Gorman wrote:
Unfortunately, this doesn't magically assist solving my problem with
71. dlloader-api.at:23: FAILED (dlloader-api.at:422)
but that's not a reason to object to the patch.
Well that sucks :(
I
On 06/17/2010 10:35 PM, Peter O'Gorman wrote:
On 06/17/2010 10:21 PM, Charles Wilson wrote:
On 6/17/2010 10:24 PM, Peter O'Gorman wrote:
Unfortunately, this doesn't magically assist solving my problem with
71. dlloader-api.at:23: FAILED (dlloader-api.at:422)
but that's not a reason to object
19 matches
Mail list logo
