[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2
From: |
KO Myung-Hun |
Subject: |
Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2 |
Date: |
Thu, 12 Oct 2017 23:05:45 +0900 |
User-agent: |
Mozilla/5.0 (OS/2; Warp 4.5; rv:10.0.6esrpre) Gecko/20120715 Firefox/10.0.6esrpre SeaMonkey/2.7.2 |
Eli Zaretskii wrote:
>> Date: Thu, 12 Oct 2017 20:49:27 +0900
>> From: KO Myung-Hun <address@hidden>
>> CC: address@hidden
>>
>>>> OS/2 cannot load DLLs whose base name is longer than 8 characters.
>>>> Because of this, libtool limits length of DLL base name up to 8
>>>> characters. In Gawk, limits likewise.
>>>
>>> Isn't it better/cleaner to have an OS/2 wrapper for dlopen, and
>>> truncate the name there? (And why doesn't dlopen itself do that, if
>>> this is an OS/2 limitation?)
>>>
>>
>> Unfortunately, wrapping dlopen() is not enough. Because gawk checks the
>> existence of extensions with find_source(). This patch is for it.
>
> Maybe I didn't understand the issue well enough. Could you please
> elaborate on it? What exactly is the limitation, which C library
> functions enforce it, and how is libtool related to this?
>
This limitation is from OS/2 itself. Considering this, libtool generates
a DLL whose base name length is not longer than 8 chars. For example, it
produces filefunc.dll not filefuncs.dll.
As a result, trying to load filefuncs extension with '@load filefuncs'
fails, because there is no filefuncs extension on OS/2.
C library function has no relations with this.
> And what happens if I compile an extension into a DLL whose file name
> has more than 8 characters in its base-name? Will such a DLL be
> completely unusable on OS/2?
>
It's possible to produce a DLL whose base name is longer than 8 chars.
However, OS/2 cannot load it. One time, there were efforts to overcome
this problem with kernel patch. It's win32k.sys in Odin project. I know,
it succeeded partially. Unfortunately, however, its development stopped.
>> I have a question. there are any cases calling load_ext() without
>> find_source() ?
>
> Doesn't look that way, but it's hard to tell.
Ok. I've updated patch.
--
KO Myung-Hun
Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM
Korean OS/2 User Community : http://www.os2.kr/
0002-Fix-plugin-load-failure-on-OS-2.patch
Description: Source code patch
- [bug-gawk] [PATCH 0/2] Fix plugin issues on OS/2, KO Myung-Hun, 2017/10/11
- [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2, KO Myung-Hun, 2017/10/11
- Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2, Eli Zaretskii, 2017/10/11
- Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2, KO Myung-Hun, 2017/10/12
- Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2, Eli Zaretskii, 2017/10/12
- Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2,
KO Myung-Hun <=
- Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2, Andrew J. Schorr, 2017/10/12
- Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2, Eli Zaretskii, 2017/10/12
- Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2, arnold, 2017/10/12
- Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2, KO Myung-Hun, 2017/10/12
- Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2, Eli Zaretskii, 2017/10/21
- Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2, arnold, 2017/10/21
- Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2, KO Myung-Hun, 2017/10/22
- Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2, arnold, 2017/10/23
- Re: [bug-gawk] [PATCH 2/2] Fix plugin load failure on OS/2, KO Myung-Hun, 2017/10/22
[bug-gawk] [PATCH 1/2] Fix dlsym() failures on OS/2 kLIBC, KO Myung-Hun, 2017/10/11