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
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 ar
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
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
* Olly Betts wrote on Fri, Jun 18, 2010 at 01:21:27PM CEST:
> On 2010-06-18, Charles Wilson wrote:
> > b3) For these reasons, it's probably best if the package
> > maintainer also provides rules for "embedding" the manifest
> > in binary form into the "real" exe. How these rul
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 "clobbe
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"
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_O
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 c
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 called, somebody -- one of the other
loaders? --
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 /usr/bin/la
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 2010-06-18, Charles Wilson wrote:
> b3) For these reasons, it's probably best if the package
> maintainer also provides rules for "embedding" the manifest
> in binary form into the "real" exe. How these rules will
> deal with the whole lt-*.exe naming problem (recom
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 (dlloader-api.
14 matches
Mail list logo
