Re: interix question
Dear Martin Köppe,
Taking the presumption that SFU 3.5 shipped the files /bin/iconv and /usr/include/iconv.h in order for the user to compile certain "new" programs, where SFU 3.5 shipped solely with gcc-3.3, and, SUA 6.0/6.1 shipped (in addition) with /usr/lib/libintl.so and /usr/lib/libintl.so.8, where likely the presence of these .so files was pertaining solely to the inclusion of gcc-4.2 (in those SUA version numbers), I think one is safe with replacing all of /bin/iconv, /usr/include/iconv.h, /usr/lib/libintl.so and /usr/lib/libintl.so.8, with new files from compiles of libiconv-1.11.tar.gz, and gettext-0.16.
I noticed (https://news.ycombinator.com/item?id=11416376) which purports to express - in referring to "the old Windows NT POSIX subsystem (the Interix-derived SFU/SFUA one)" which "has an init process (and an inetd)" - the doubt (in the final paragraph) "that the new Windows NT Linux subsystem has (or will have) anything similar".
http://nurmi-labs.blogspot.com/2017/01/xs.html
Recently, considering XS, I started to think about Interix again, mainly about the possibility to compile boost.
Sincerely,
Eric Lindblad
--------------------------------------------
On Fri, 2/3/17, Martin Koeppe <mkoeppe@gmx.de> wrote:
Subject: Re: interix question
To: "Eric Lindblad" <geirfuglaps@yahoo.com>
Cc: "debian-interix list" <debian-interix@lists.debian.org>
Date: Friday, February 3, 2017, 6:22 PM
Hi Eric,
ah, I see. I don't expect much problems, because most of the MS supplied binaries were built with MSVC and are therefore statically linked. Only gcc can produce dynamically linked binaries.
You can check the binaries with "file" and_ "ldd".
I expect, however, that you will encounter much more and much harder "problems" than just with iconv/libintl when building more stuff. (You could also just disable iconv support while running ./configure in this case.)
Good luck
Martin
Reply to: