> On 25. Mar 2021, at 18:12, cretin1997 via oi-dev <[email protected]> > wrote: > > On Thursday, March 25, 2021 8:43 PM, Bob Friesenhahn > <[email protected]> wrote: > >> On Thu, 25 Mar 2021, cretin1997 via oi-dev wrote: >> >>> The current crt headers of FreeBASIC is exclusively based on Linux: >>> https://github.com/freebasic/fbc/tree/master/inc/crt >>> 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: >>> First, it could be my removing of --export-dynamic caused the FreeBASIC >>> compiler to generate a not working shared library. >> >> This seems like the most unlikely cause. :-) >> > > 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.
We are using dlopen() in many components as you can see with http://src.illumos.org/source/search?full=&defs=&refs=dlopen&path=&hist=&type=&xrd=&nn=1&si=refs&searchall=true&si=refs <http://src.illumos.org/source/search?full=&defs=&refs=dlopen&path=&hist=&type=&xrd=&nn=1&si=refs&searchall=true&si=refs> however, we do not build with gnu ld (in general), and therefore there is no —export-dynamic. rgds, toomas > >>> 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. >> >> This is exceedingly likely. Although Linux is originally modelled on >> SunOS (a clone of Unix), it did not directly copy it. The GNU libc >> (much of what you call a "CRT") is independent of Linux, so it also >> makes its own decisions. >> >> From looking at the translated ".bi" files (e.g. >> https://github.com/freebasic/fbc/blob/master/inc/crt/io.bi), there are >> many arbitrary constant values which were translated from system >> headers. An API may be the "same" (be compliant to a standard) even >> if the integer values representing it are different. >> >> At the top of the referenced header I see "io -- header translated >> with help of SWIG FB wrapper". >> >> It seems that the methodology used to create this files needs to be >> replicated in order to produce similar files for Illumos. >> > > 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. > > The modern tool for this purpose is fbfrog: > > https://github.com/freebasic/fbfrog > > 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). > >>> Please note that the application could be launched, but it just sit >>> there idle and doesn't print any output on the terminal. I have to >>> use Ctrl+C to cancel it. >> >> This is not surprising. What means "start" in Linux may very well >> mean "stop" in Illumos. >> >> It does not appear that the git structure of the FreeBASIC files is >> designed to support porting since it does not even mention that these >> files are translations of Linux/glibc header content. >> > > 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. > > 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,...). > >> Python does similar things, but it is designed for porting. >> >> Bob >> >> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- >> >> Bob Friesenhahn >> [email protected], http://www.simplesystems.org/users/bfriesen/ >> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/ >> Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt >> >> oi-dev mailing list >> [email protected] >> https://openindiana.org/mailman/listinfo/oi-dev > > _______________________________________________ > oi-dev mailing list > [email protected] > https://openindiana.org/mailman/listinfo/oi-dev
_______________________________________________ oi-dev mailing list [email protected] https://openindiana.org/mailman/listinfo/oi-dev
