[smartmontools-support] State of OS/2 port

[Dave Yeo]

Christian Franke wrote:
> Dave Yeo wrote:
>> ...
>> smartctl.exe runs fine here.
>
> Thanks.
>
>
>> It is big compared to the one I built, 5.8MB compared to 1.1MB.
>
> This is because ./configure sets -g by default which adds plenty of
> debug info. The size without -g (aka after ...-strip) is reasonable:
>
> $ i686-pc-os2-emx-size *.exe
>    text    data     bss     dec     hex filename
>  864256   81920   77264 1023440   f9dd0 smartctl.exe
>  614400   61440   12768  688608   a81e0 smartd.exe
>
> $ ls -1hs *.exe
> 5.6M smartctl.exe
> 4.2M smartd.exe
>
> $ i686-pc-os2-emx-objdump -f smartctl.exe
> smartctl.exe:     file format a.out-emx
> ...
>
> $ i686-pc-os2-emx-strip *.exe
>
> $ ls -1hs *.exe
> 940K smartctl.exe
> 676K smartd.exe

Ok, configure doesn't add -g here, also defaults to i386. Adding 
CXXFLAGS=-g -march=i686 gives me similar results

>
>
>> I'd suggest using LDFLAGS=-Zomf in the configure arguments. GCC
>> outputs aout objects on OS/2, the -Zomf calls emxomf to convert to OMF
>> (obj) format and uses the system linker (OpenWatcom's wlink in this
>> case) instead of the ancient ld, which is so old it is GPL v1 authored
>> by RMS, with lots of updates over the years.
>
> $ ./configure --build=$(./config.guess) --host=i686-pc-os2-emx
> LDFLAGS=-Zomf
> $ make ...
> $ cd src
>
> $ ls -1hs *.exe
> 2.3M smartctl.exe
> 1.8M smartd.exe
>
> $ i686-pc-os2-emx-strip *.exe
> i686-pc-os2-emx-strip: smartctl.exe: file format not recognized
> i686-pc-os2-emx-strip: smartd.exe: file format not recognized

STRIP=emxomfstrip or perhaps =i686-pc-os2-emx-emxomfstrip
There's also lxlite which will also compress the binary by removing a 
lot of empty space as well as removing the debug info.

>
>
> $ ./configure --build=$(./config.guess) --host=i686-pc-os2-emx
> CXXFLAGS=-O2 LDFLAGS=-Zomf
> $ make ...
> $ cd src
>
> $ ls -1hs *.exe
> 1.5M smartctl.exe
> 1.2M smartd.exe
>
> Not smaller than with aout.
>
>
>>
>>>
>>> Fully static build did not work because the required libraries are not
>>> included in the package.
>>
>> Libc (libcn0.dll) is not available statically due to licensing.
>
> But it's packaged with the toolchain...

Hmm, have to look. Maybe that ld and emxomfld refuse to statically link it.
KOMH has made quite a few changes, including to ld which may be why it 
is working well for you. He also got gdb working again with aout builds. 
For the longest time the only debuggers that worked were the IBM ones 
and another reason for needing -Zomf.

>
>
>> It is usually not packaged with binaries to make sure the system
>> libcn0.dll is loaded.
>
> I'll remove it from the artifact.

Good.

>
>
>> Weird bugs when an older libc is loaded by something before the system
>> one as it is used globally.
>>
>>> Build of the shared library (libsmartmon.dll) is apparently not
>>> supported by libtool on this platform.
>>
>> Try --enable-shared --disable-static, should build smartmon.dll, or
>> here smartmo0.dll.
>
> Does not work for me:
>
>   libtool: warning: undefined symbols not allowed in i686-pc-os2-emx
> shared libraries; building static only
>
> This is as expected. After adding this to lib/Makefile (which as also
> required for the Windows DLL build)...
>
>   libsmartmon_la_LDFLAGS = -no-undefined

Yes, forgot about upstream libtool often needing -no-undefined. 
Interestingly here, only needed it after add CXXFLAGS=-g -march=i686

>
> ... the result is:
>
> emxbind: Invalid statement (line 1 of .libs/smartmon.def)
> /opt/os2emx/bin/../lib/gcc/i686-pc-os2-emx/15/../../../../i686-pc-os2-emx/bin/ld:
> emxbind failed
>
> $ head -2 lib/.libs/smartmon.def
> LIBRARY smartmo0 INITINSTANCE TERMINSTANCEnDESCRIPTION "smartmon"nDATA
> MULTIPLE NONSHAREDnEXPORTSn  ; segment DATA32
> "__ZN8smartmon12packet_typesE" ; magicseg='DATA32' len=28

Yes, it is malformed, those n should be EOL,
K:\work\smartmontools\obj\lib\.libs>head -6 smartmo0.def
LIBRARY smartmo0 INITINSTANCE TERMINSTANCE
DESCRIPTION "smartmon"
DATA MULTIPLE NONSHARED
EXPORTS
   ; segment DATA32
   "__ZN8smartmon12packet_typesE" 
; magics
eg='DATA32' len=28

>
>
> Note that I use the upstream version of libtool[ize] because
> ./autogen.sh is run under ubuntu to generate the source tarball.

While usually use our port, which unluckily the maintainer doesn't try 
to get fixes upstream, regular libtool does usually work, sometimes 
needing -no-undefined as well as I use LDFLAGS=-Zomf
Upstream libtool is also more limited, can't pass a def file or handle 
declspec(export).

>
>
>> OS/2 is limited to 8.3 DLL naming.
>
> Oh yes, I forgot, OS/2 usage is far too long ago (1994..2003). For which
> purposes is such an OS still in use today ?-)

There are still instances running in back rooms in various enterprises, 
embedded devices and such, as well as hobbyist like me. Arca Noae seems 
to be making some money of it as if you want to run OS/2 on modern 
hardware, it is the only choice besides virtualization.

>
>
>> The lib prefix is also optional for static libs.
>> By default, configure only built a static library here,
>
> This is because I decided to start with LT_INIT([disable_shared]) when
> the library feature was added (1994d3316a0).
>
>
>> it is probably best to stick to static to avoid LIBPATH issues.
>
> Yes.
>

Thanks
Dave