[fpc-devel] OS/2 and DLLs

Dave Parsons dwparsons at t-online.de
Thu Dec 18 12:08:23 CET 2014

Hi Tomas,

On 17-12-14 21:30, Tomas Hajny wrote:
> On 17 Dec 14, at 19:27, Dave Parsons wrote:
> Hi Dave,
>> I needed to create an OS/2 DLL today&  was disappointed by the compiler (v2.6.4) telling me that they were not supported.
>> http://www.freepascal.org/faq.var#os2-dll section 6.3 seems to agree but is rather old.
>> Can anyone confirm that this is still true?
> Yes, it's still the case.
>> Google didn't find much and it is not mentioned on  the Future Plans page.
>> What is the reason?
>>     Too difficult, no demand/request, no time or whatever.
> The primary reason is the fact that creation of DLLs is not supported
> by the ancient EMX port of the GNU linker ld.exe. As far as I know,
> OS/2 ports of GCC (both the original EMX port and the recent ones)
> solve this issue by using the IBM linker (possibly masked by EMXOMFLD
> binary). However, this has several caveats (no special order):
> 1) Object files need to be translated/transformed from the a.out
> format supported by the GNU binutils (as.exe and ld.exe) to Intel OMF
> expected by the IBM linker (e.g. using the tool EMXOMF supplied with
> EMX), or they need to be assembled using a different assembler
> supporting this format (such as Watcom assembler or NASM) from the
> very beginning, or support for direct creation of object files in
> this format needs to be added to FPC directly. When I tried
> translating object files created by FPC (using as.exe) with EMXOMF
> some time ago, it failed to process some of them. I didn't manage to
> find out the reasons so that I could possibly fix them at that point
> in time (no we get to amount of time available mentioned by you).
> 2) Binaries linked with IBM LINK.EXE cannot be debugged using
> GDB/PMGDB any longer (and no other debugger either, in fact, because
> LINK.EXE would not support the stabs debug format which is currently
> the only alternative supported for the OS/2 target in FPC).
> 3) There are certain special features which would need to be solved
> differently if using a different linker (e.g. support for direct port
> access). These wouldn't prevent most common uses, but they would
> require spending some time on their resolution too.
> Now back to your questions:
> 1) Is it possible to solve it? Yes, certainly.
> 2) Does the resolution require considerable amount of time? Yes, it
> probably does (especially if the only person working on it is me).
> 3) Has there been strong demand? Well, not really (although some
> questions already arose in the past).
> I don't have much time for working on this task, but I'm willing to
> spend some time on it as soon as I finish my current work on finally
> properly supporting all UnicodeString Manager functions for OS/2
> (that requires some time, but it is quite simple from technical point
> of view). My motivation to work on the linker issue would be higher
> if someone else joins me in this effort. Feel free to contact me
> directly if you're interested.
> Tomas

Thanks for the information.

At first glance it looks like the best way forward might be to give up EMX & use Watcom since we already have wasm support.

Anyway I'll think about it a bit more & contact you directly.


More information about the fpc-devel mailing list