<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On 25. Mar 2021, at 18:12, cretin1997 via oi-dev <<a href="mailto:oi-dev@openindiana.org" class="">oi-dev@openindiana.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Thursday, March 25, 2021 8:43 PM, Bob Friesenhahn <<a href="mailto:bfriesen@simple.dallas.tx.us" class="">bfriesen@simple.dallas.tx.us</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">On Thu, 25 Mar 2021, cretin1997 via oi-dev wrote:<br class=""><br class=""><blockquote type="cite" class="">The current crt headers of FreeBASIC is exclusively based on Linux: <a href="https://github.com/freebasic/fbc/tree/master/inc/crt" class="">https://github.com/freebasic/fbc/tree/master/inc/crt</a><br class="">In order to build GTK based FreeBASIC application, one has to have a working crt headers set, too. There is no such thing for OpenIndiana. I and other FreeBASIC users decided to just copy the Linux crt headers and modify them to use with OpenIndiana. The result is we could build the application successfully but unfortunately this application can't run. I think there could be two potential problems:<br class="">First, it could be my removing of --export-dynamic caused the FreeBASIC compiler to generate a not working shared library.<br class=""></blockquote><br class="">This seems like the most unlikely cause. :-)<br class=""><br class=""></blockquote><br class="">No, it's more likely than you think. As I recall --export-dynamic is needed for dlopen and friends. VisualFBEditor_gtk3 is not linked with libmff64_gtk3.so but will load libmff64_gtk3.so dynamically on startup, this means something like dlopen is used.<br class=""></div></div></blockquote><div><br class=""></div><div><br class=""></div><div>We are using dlopen() in many components as you can see with <a href="http://src.illumos.org/source/search?full=&defs=&refs=dlopen&path=&hist=&type=&xrd=&nn=1&si=refs&searchall=true&si=refs" class="">http://src.illumos.org/source/search?full=&defs=&refs=dlopen&path=&hist=&type=&xrd=&nn=1&si=refs&searchall=true&si=refs</a></div><div><br class=""></div><div>however, we do not build with gnu ld (in general), and therefore there is no —export-dynamic.</div><div><br class=""></div><div>rgds,</div><div>toomas</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Second, it could be the Linux crt headers are incompatible with OpenIndiana, the C standard functions are the same but the platform specific details (#define bla bla) are different, so the application could be compiled, but it used the wrong details so it can't run.<br class=""></blockquote><br class="">This is exceedingly likely. Although Linux is originally modelled on<br class="">SunOS (a clone of Unix), it did not directly copy it. The GNU libc<br class="">(much of what you call a "CRT") is independent of Linux, so it also<br class="">makes its own decisions.<br class=""><br class="">From looking at the translated ".bi" files (e.g.<br class=""><a href="https://github.com/freebasic/fbc/blob/master/inc/crt/io.bi" class="">https://github.com/freebasic/fbc/blob/master/inc/crt/io.bi</a>), there are<br class="">many arbitrary constant values which were translated from system<br class="">headers. An API may be the "same" (be compliant to a standard) even<br class="">if the integer values representing it are different.<br class=""><br class="">At the top of the referenced header I see "io -- header translated<br class="">with help of SWIG FB wrapper".<br class=""><br class="">It seems that the methodology used to create this files needs to be<br class="">replicated in order to produce similar files for Illumos.<br class=""><br class=""></blockquote><br class="">This again need the FreeBASIC developers to step up. I have no idea about this tool. I only know they patched an ancient version of Swig to add FreeBASIC support and they used this tool to generate most of the headers in the inc directory.<br class=""><br class="">The modern tool for this purpose is fbfrog:<br class=""><br class=""><a href="https://github.com/freebasic/fbfrog" class="">https://github.com/freebasic/fbfrog</a><br class=""><br class="">fbfrog doesn't support Solaris target. The original tool used to generate the headers as I know is provided as a Windows binary, it's very unlikely that it supports anything different than Windows and Linux (maybe DOS, too).<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">Please note that the application could be launched, but it just sit<br class="">there idle and doesn't print any output on the terminal. I have to<br class="">use Ctrl+C to cancel it.<br class=""></blockquote><br class="">This is not surprising. What means "start" in Linux may very well<br class="">mean "stop" in Illumos.<br class=""><br class="">It does not appear that the git structure of the FreeBASIC files is<br class="">designed to support porting since it does not even mention that these<br class="">files are translations of Linux/glibc header content.<br class=""><br class=""></blockquote><br class="">No, they do mention which header is for which platform. For example, you could see they clearly state in iconv.bi that this is translated from glibc's iconv. I have to hack this header to be able to use it for iconv on FreeBSD and OpenIndiana.<br class=""><br class="">The headers in crt is generic, they will according to predefined platform macro (e.g: __FB_LINUX__, __FB_WIN32__,...) to include the correct platform specific header on the platform's own directory (e.g: crt/win32, crt/linux,...).<br class=""><br class=""><blockquote type="cite" class="">Python does similar things, but it is designed for porting.<br class=""><br class="">Bob<br class=""><br class="">---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------<br class=""><br class="">Bob Friesenhahn<br class="">bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/<br class="">GraphicsMagick Maintainer, http://www.GraphicsMagick.org/<br class="">Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt<br class=""><br class="">oi-dev mailing list<br class="">oi-dev@openindiana.org<br class="">https://openindiana.org/mailman/listinfo/oi-dev<br class=""></blockquote><br class="">_______________________________________________<br class="">oi-dev mailing list<br class="">oi-dev@openindiana.org<br class="">https://openindiana.org/mailman/listinfo/oi-dev<br class=""></div></div></blockquote></div><br class=""></body></html>