Re: [oi-dev] Could I reuse the Linux crt headers for OpenIndiana?
On Thursday, March 25, 2021 8:43 PM, Bob Friesenhahn 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. > > 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 > bfrie...@simple.dallas.tx.us, 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 > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Fw: Re: What is the equivalent for GNU ld's --export-dynamic?
‐‐‐ Original Message ‐‐‐ On Thursday, March 25, 2021 8:18 PM, Bob Friesenhahn wrote: > > Properly written software will self-diagnose if something as simple as > failing to resolve a symbol occurs. > > Bob > The problem is code written by the FreeBASIC forum members are not anything like you said. We are all amateur and code for fun. The language we chose alone tell you all about it, BASIC. Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Trouble compiling Juci++ IDE
‐‐‐ Original Message ‐‐‐ On Thursday, March 25, 2021 6:30 PM, Udo Grabowski (IMK) wrote: > No, no that solution, seems you're referring to some different bug > with text blinking, not cursor blinking. > > On 25.03.21 12:21, Udo Grabowski (IMK) wrote: > > > On 25.03.21 11:59, cretin1997 via oi-dev wrote: > > > > > ...It has the same bug when the text will not stop blinking as Pluma > > > and that bug was not yet solved. ... > > > > It's a feature, not a bug: > > open dconf-editor > > set /org/gnome/desktop/interface/cursor-blink-timeout to a very > > large value > > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev Everything back to be reasonable now. A developer told me it could be caused by this mismatch between libraries version and he said he will upload new packages soon. I don't know if he updated the packages or not but the problem is still there. Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Trouble compiling Juci++ IDE
‐‐‐ Original Message ‐‐‐ On Thursday, March 25, 2021 6:21 PM, Udo Grabowski (IMK) wrote: > On 25.03.21 11:59, cretin1997 via oi-dev wrote: > > > ...It has the same bug when the text will not stop blinking as Pluma > > and that bug was not yet solved. ... > > It's a feature, not a bug: > > open dconf-editor > set /org/gnome/desktop/interface/cursor-blink-timeout to a very > large value > > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev Oh. What a "feature"! The entire text on the file blinking, not only the cursor itself. I considered it a serious bug, turned out this is a "feature"? I have used many Linux with MATE as the desktop environment and a FreeBSD, too, none have such "feature" at all. Could this be considered as a bad default? BTW, thank you for pointing out this "feature" to me. Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Fw: Re: What is the equivalent for GNU ld's --export-dynamic?
‐‐‐ Original Message ‐‐‐ > On Thursday, March 25, 2021 4:38 PM, Toomas Soome tso...@me.com wrote: > > > How did you test the library? are you sure it is fault of linker and not > > the code? running the app and getting no output does only prove that there > > is a problem, bit it does not identify the problem. > > If that library is working on FreeBSD, it means the FreeBSD port is done > > correctly, it does not tell you anything about illumos port because > > building on FreeBSD does not tell anything about illumos. > > rgds, > > toomas > Perhaps the FreeBASIC forum thread is too long and confusing. There are two guys tested on FreeBSD: me and another guy. First, the guy ported FreeBASIC to FreeBSD/PowerPC and failed to compile the code, so he seek for help. Second, I come to help him by testing compiling the code on FreeBSD/x86_64, a more matured port. This turned out the problem with strings is his port specific, since PowerPC is Big Endian and the code was written with Little Endian in mind. Later he switched to the Little Endian version of PowerPC. The next problem diagnosed by us is the missing of the crt headers for FreeBSD in general, both PowerPC/LE and x86_64. I always work on the Solaris port. I did compile the code on OpenIndiana and test on OpenIndiana. Don't treat me as a fool or fraud, I will not bring a FreeBSD problem to discuss here. How did I test the library? The VisualFBEditor IDE was based on MyFbFramework from the same author. I compile MyFbFramework into a shared library and VisualFBEditor will load this library on startup. The library will be loaded dynamically, it was not linked with the binary VisualFBEditor_gtk3 itself. This is the reason why now I think it's more likely the side effect when I removed --export-dynamic more than the Linux crt headers being incompatible with OpenIndiana. Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Could I reuse the Linux crt headers for OpenIndiana?
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. 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. 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. FreeBASIC forum thread for more details: https://www.freebasic.net/forum/viewtopic.php?f=8=27284=240 Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Fw: Re: Is it possible for OpenIndiana and DilOS to cooperate together?
> ‐‐‐ Original Message ‐‐‐ > On Thursday, March 25, 2021 2:45 AM, Chris oi...@sunos.info wrote: > > > On 2021-03-24 05:59, cretin1997 via oi-dev wrote: > > > > > I'm honest, I liked DilOS more than OpenIndiana. But OI is the only > > > working > > > graphical Illumos and I have no other choices. > > > DilOS wanted to support graphical environment, too. I asked Igor about > > > that > > > and he > > > gave me the milestones. The day DilOS will have a desktop is too far in > > > the > > > future. > > > So what about the possibility of cooperating between two projects? DilOS > > > will give > > > OpenIndiana a much better base and OpenIndiana could help a graphical > > > DilOS > > > possible. > > > > > Imagine, DilOS is Debian and OpenIndiana is Ubuntu. Both sides will win, > > > and the users will win, too. > > > > Sort of. > > I'm not keen on the idea of ZoL (ZFSonLinux) the OI version is better. :-) > > Package management; while I suppose it's easy to use a DEB package manager, > > and import a bunch of Linux based applications. In the short run, it'd be a > > LOT > > of work, and a seemingly good amount of Linux shims for OI to introduce. Is > > this > > the best plan for the long run? > > OTOH if their graphics stack is better/more polished. Hijacking for OI seems > > tempting. :-) > > Mind you these are my opinions, and may, or may not be shared by others. > > :-) > > --Chris > > > > > Please let me know what the two sides think about this. Sorry Igor, I > > > know I > > > should ask you first but I posted there anyway and waiting for the answers > > > from > > > both of you. > > > Sent with ProtonMail Secure Email. > > > oi-dev mailing list > > > oi-dev@openindiana.org > > > https://openindiana.org/mailman/listinfo/oi-dev > > > > -- > > ~10yrs a FreeBSD maintainer of ~160 ports > > ~40yrs of UNIX > As I know, DilOS doesn't introduce any new Linux shims. They just grab Debian's packages sources, patch it to build on their OS and packaged it. Alongside with that, DilOS also provided many of it own packages, too. It's not a Debian/kIllumos. It uses Debian packaging technology and Debian packages sources to minimize the maintenance effort. And no, it doesn't have a superior graphics stack than OI. OI's graphics stack is the best on the Illumos world. DilOS's graphics stack is almost non-existent. I can't even install the xorg package because of umet dependencies! DilOS seems to use the same framework as OI to build packages, but they hacked it to produce DEB packages instead of IPS packages. Integrating OI userland into it seems to not as difficult as you think. OI doesn't have to maintain any Linux shims like that said. On a plain DilOS system, one could add the APT repo of OI, then after that: apt update && apt install mate-install Done. We will have a working graphical environment on DilOS, based on OI's works. I can't think of any problems when rebasing OI on DilOS at all. If OI want to be "Hipster" it could track the unstable or testing branch of DilOS, it's almost as rolling release as the current Hipster. Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What is the equivalent for GNU ld's --export-dynamic?
‐‐‐ Original Message ‐‐‐ On Thursday, March 25, 2021 1:43 AM, Bob Friesenhahn wrote: > On Wed, 24 Mar 2021, cretin1997 via oi-dev wrote: > > > I know the Solaris linker is what caused all of the trouble. > > FreeBASIC expects a GNU linker. This time is the same. The Solaris > > ld doesn't support --export-dynamic. > > The Solaris linker has not caused a problem. It seems like the Linux > linker has caused the problem! :-) > > I suggest trying without the option. If there is some problem later > with resolving symbols while actually running the program, then return > to the issue. > > If one looks at the Linux dlopen(3) manual page, there is a > RTLD_GLOBAL option. Apparently this used to be the Linux default, > then but then RTLD_LOCAL became the default due to security concerns. > It is my experience that Illumos will still behave as described for > RTLD_GLOBAL: > > "The symbols defined by this shared object will be made available for > symbol resolution of subsequently loaded shared objects." > > > Put this shit aside, what I do is I just removed the problematic > > option. FreeBASIC does turn on it option for Linux. I don't know > > what it does, nor I wanted to know, I only wanted to know the > > equivalent option for the Solaris linker. If no such equivalent > > option available, does the shared library produced by FreeBASIC with > > --export-dynamic removed work? What is the side effect if without > > --export-dynamic? This is the only thing I wanted to know! The one > > most qualified to answer such question should be the FreeBASIC > > developers, but, as you already known... do it yourself and you > > could submit the code to us! > > Since you are porting the code, you will soon learn if it works. > > Trial and error is a valid approach. > > Bob > > -- > > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, 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 > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev No. The GNU linker is not a problem. It is widely used across platforms. It's nothing wrong for the developers to insist it's the default. Even on platform doesn't use the GNU linker by default like FreeBSD, it's easily installed from ports/packages and it will just work. It is you, a weirded platform, with it incompatible linker, that caused the problem. As I said many times before and being hated because of this but I will not afraid said it again: software developers will just skip your platforms and support other platforms that they will have the least effort to support, that is platforms that behave almost identical to their first class platform, usually be Linux. Perhaps you didn't read my last email. OK, it's too long, I myself tired to read it, too. I did try to remove --export-dynamic and after that I could have the compiler to generate a shared library (.so file). And you are right, trial and error is the only solution, because I have no one to mentor, no one to ask for. But unfortunately, it seemed the produced shared library doesn't work. The program linked with it will just sit there but do nothing, it doesn't even seem to be launched, indicating that it failed to load the shared library or the shared library simply doesn't work. Someone on the internet said I should run truss on the binary, I did and I found after a while the program just sit there idle. No outputs were even printed by this program to the terminal. It just stuck and needs to be canceled with Ctrl+C. Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What is the equivalent for GNU ld's --export-dynamic?
‐‐‐ Original Message ‐‐‐ On Wednesday, March 24, 2021 11:29 PM, cretin1997 via oi-dev wrote: > ‐‐‐ Original Message ‐‐‐ > On Wednesday, March 24, 2021 11:03 PM, Bob Friesenhahn > bfrie...@simple.dallas.tx.us wrote: > > > On Wed, 24 Mar 2021, cretin1997 via oi-dev wrote: > > > > > I currently remove the option because I don't know the equivalent for > > > Sun's ld. This allowed the compiler to successfully generate a shared > > > library file but I didn't test to see if this shared library even work or > > > not. I think better ask first before actually push the changes. Yes, of > > > course I'm using git, in case any of you ask me about that. > > > > Do you actually need this option? This option enables shared > > libraries to resolve symbols from the program (e.g. using > > dlopen(),dlsym()) which loaded them. It also causes the executable to > > expose all of its extern symbols, which will make the program more > > bloated, and likely less optimized. > > Solaris and modern Linux defaults are different regarding default > > symbol visibility. Linux has become more restrictive. > > Bob > > > > Bob Friesenhahn > > bfrie...@simple.dallas.tx.us, 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 > > oi-dev@openindiana.org > > https://openindiana.org/mailman/listinfo/oi-dev > > Honestly I don't know. I'm just a completely amateur. The FreeBASIC compiler > is not designed with portability in mind but their architecture allow them to > be fairly portable, very easy to port to new platforms. I contact the > developers asked for Illumos support, as usual with FOSS project they told me > to do the porting myself, it's easy, they said. They give me a list of source > files I need to edit to adapt the code to the new platform. After many days > of trial and error finally I have a working FreeBASIC compiler on > OpenIndiana, possible to generate working binary. But the problem is I didn't > test the compilation of shared library. So when I try to compile one, it > failed immediately. > > I know the Solaris linker is what caused all of the trouble. FreeBASIC > expects a GNU linker. This time is the same. The Solaris ld doesn't support > --export-dynamic. > > I adapt the code for Solaris by blindly translate from the Linux ones. I > don't understand the internal working of the compiler. If will much better if > the developers do the porting themselves. But, you already know, when you > want something and you go to the developers of a FOSS project, they don't > care if you really have the ability to do it or not but will always said this > famous statement: do it yourself, you can submit the code to us. This > including this OpenIndiana, too. And you think what I could do with it? I > really do it myself, without assistant from them, no one to ask when you have > questions, no one at all, and they have not even merged my pull request > (contains fixes for dealing with the Solaris linker). > > Sometimes I really hope I'm rich. I will dump the FOSS software into the > trash can and buy commercial ones. At least, I will have someone to answer to > me. But it's just my own delusional. I'm unemployed for more than 5 yrs. > > Put this shit aside, what I do is I just removed the problematic option. > FreeBASIC does turn on it option for Linux. I don't know what it does, nor I > wanted to know, I only wanted to know the equivalent option for the Solaris > linker. If no such equivalent option available, does the shared library > produced by FreeBASIC with --export-dynamic removed work? What is the side > effect if without --export-dynamic? This is the only thing I wanted to know! > The one most qualified to answer such question should be the FreeBASIC > developers, but, as you already known... do it yourself and you could submit > the code to us! > > Sent with ProtonMail Secure Email. > > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev I don't want to bad mouth about them. They are just the same as any other FOSS project, including this OpenIndiana. They indeed did an amazing job, giving a too small development team and too small user base. I don't blame them. They worked for free after all! Amending to the previous lengthy but no useful information email, I want to add that after I removed --export-dynamic I actually could have the compiler to successfully generated a shared library (.so file) for me. The only problem is I don't kno
Re: [oi-dev] What is the equivalent for GNU ld's --export-dynamic?
‐‐‐ Original Message ‐‐‐ On Wednesday, March 24, 2021 11:03 PM, Bob Friesenhahn wrote: > On Wed, 24 Mar 2021, cretin1997 via oi-dev wrote: > > > I currently remove the option because I don't know the equivalent for Sun's > > ld. This allowed the compiler to successfully generate a shared library > > file but I didn't test to see if this shared library even work or not. I > > think better ask first before actually push the changes. Yes, of course I'm > > using git, in case any of you ask me about that. > > Do you actually need this option? This option enables shared > libraries to resolve symbols from the program (e.g. using > dlopen(),dlsym()) which loaded them. It also causes the executable to > expose all of its extern symbols, which will make the program more > bloated, and likely less optimized. > > Solaris and modern Linux defaults are different regarding default > symbol visibility. Linux has become more restrictive. > > Bob > > > > Bob Friesenhahn > bfrie...@simple.dallas.tx.us, 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 > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev Honestly I don't know. I'm just a completely amateur. The FreeBASIC compiler is not designed with portability in mind but their architecture allow them to be fairly portable, very easy to port to new platforms. I contact the developers asked for Illumos support, as usual with FOSS project they told me to do the porting myself, it's easy, they said. They give me a list of source files I need to edit to adapt the code to the new platform. After many days of trial and error finally I have a working FreeBASIC compiler on OpenIndiana, possible to generate working binary. But the problem is I didn't test the compilation of shared library. So when I try to compile one, it failed immediately. I know the Solaris linker is what caused all of the trouble. FreeBASIC expects a GNU linker. This time is the same. The Solaris ld doesn't support --export-dynamic. I adapt the code for Solaris by blindly translate from the Linux ones. I don't understand the internal working of the compiler. If will much better if the developers do the porting themselves. But, you already know, when you want something and you go to the developers of a FOSS project, they don't care if you really have the ability to do it or not but will always said this famous statement: do it yourself, you can submit the code to us. This including this OpenIndiana, too. And you think what I could do with it? I really do it myself, without assistant from them, no one to ask when you have questions, no one at all, and they have not even merged my pull request (contains fixes for dealing with the Solaris linker). Sometimes I really hope I'm rich. I will dump the FOSS software into the trash can and buy commercial ones. At least, I will have someone to answer to me. But it's just my own delusional. I'm unemployed for more than 5 yrs. Put this shit aside, what I do is I just removed the problematic option. FreeBASIC does turn on it option for Linux. I don't know what it does, nor I wanted to know, I only wanted to know the equivalent option for the Solaris linker. If no such equivalent option available, does the shared library produced by FreeBASIC with --export-dynamic removed work? What is the side effect if without --export-dynamic? This is the only thing I wanted to know! The one most qualified to answer such question should be the FreeBASIC developers, but, as you already known... do it yourself and you could submit the code to us! Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Is it possible for OpenIndiana and DilOS to cooperate together?
I'm honest, I liked DilOS more than OpenIndiana. But OI is the only working graphical Illumos and I have no other choices. DilOS wanted to support graphical environment, too. I asked Igor about that and he gave me the milestones. The day DilOS will have a desktop is too far in the future. So what about the possibility of cooperating between two projects? DilOS will give OpenIndiana a much better base and OpenIndiana could help a graphical DilOS possible. Imagine, DilOS is Debian and OpenIndiana is Ubuntu. Both sides will win, and the users will win, too. Please let me know what the two sides think about this. Sorry Igor, I know I should ask you first but I posted there anyway and waiting for the answers from both of you. Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Geany problem
‐‐‐ Original Message ‐‐‐ On Wednesday, March 24, 2021 7:34 PM, Stephan Althaus wrote: > On 03/24/21 01:23 PM, cretin1997 via oi-dev wrote: > > > I was shut up from the oi-discuss mail list so hopefully I still allowed to > > post here freely. I don't attempt to hide my identity so don't even call me > > as a troll, it's an serious insult to me. > > On latest OI, the Geany program has problem displaying the underscores on > > code. The underscores will be invisible even though they are still there. > > Saving the file confirmed that it's a display problem because it didn't > > remove the underscores from the file. > > BTW, I wanted to kindly remind you of the problem with Pluma crashing > > frequently I reported on the oi-discuss mail list. I have never received > > any news about it since then. I still watch the mail list archive by date > > so even though I'm unsubscribed from it I still not missed anything. > > Sent with ProtonMail Secure Email. > > > > oi-dev mailing list > > oi-dev@openindiana.org > > https://openindiana.org/mailman/listinfo/oi-dev > > Hello! > > I have it on my geany too. > > You can solve it by changing the editor-font in the geany-preferences to > something like 'DejaVu Sans Mono Book' size 11. > > Stephan > > oi-dev mailing list > oi-dev@openindiana.org > https://openindiana.org/mailman/listinfo/oi-dev Thanks. I didn't think about that because I always use the default font. Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] What is the equivalent for GNU ld's --export-dynamic?
I'm porting a compiler to OpenIndiana. The fact is I started the job long before I joined oi-discuss and being "moderated" and then unsubscribed. Even after unsubscribed from the mail list, I still keep working on this porting effort. I currently remove the option because I don't know the equivalent for Sun's ld. This allowed the compiler to successfully generate a shared library file but I didn't test to see if this shared library even work or not. I think better ask first before actually push the changes. Yes, of course I'm using git, in case any of you ask me about that. Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
[oi-dev] Geany problem
I was shut up from the oi-discuss mail list so hopefully I still allowed to post here freely. I don't attempt to hide my identity so don't even call me as a troll, it's an serious insult to me. On latest OI, the Geany program has problem displaying the underscores on code. The underscores will be invisible even though they are still there. Saving the file confirmed that it's a display problem because it didn't remove the underscores from the file. BTW, I wanted to kindly remind you of the problem with Pluma crashing frequently I reported on the oi-discuss mail list. I have never received any news about it since then. I still watch the mail list archive by date so even though I'm unsubscribed from it I still not missed anything. Sent with ProtonMail Secure Email. ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
