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] What is the equivalent for GNU ld's --export-dynamic?
On 2021-03-24 21:27, cretin1997 via oi-dev wrote: ‐‐‐ 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. Regarding your FreeBASIC adventure; It sounds like your lib (.so file) is blocking on something. Is it possible to build it again with DEBUG symbols? This would cause it to be more informative during load/execution and that would tell us where it's blocking, and what it's expecting, or waiting for. Also, does it allow starting in a VERBOSE mode? Maybe a -v , -V or --verbose switch? This may also provide the clues needed to resolve the problem. Congrats on your progress so far with it! --Chris Sent with ProtonMail Secure Email. -- ~10yrs a FreeBSD maintainer of ~160 ports ~40yrs of UNIX ___ 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] Could I reuse the Linux crt headers for OpenIndiana?
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. :-) 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. 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. 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
Re: [oi-dev] Fw: Re: What is the equivalent for GNU ld's --export-dynamic?
On Thu, 25 Mar 2021, cretin1997 via oi-dev wrote: 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. It seems that you are making mere assumptions here. Surely it is not difficult to find the actual cause? Properly written software will self-diagnose if something as simple as failing to resolve a symbol occurs. 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
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
Re: [oi-dev] Trouble compiling Juci++ IDE
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 smime.p7s Description: S/MIME Cryptographic Signature ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Trouble compiling Juci++ IDE
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 smime.p7s Description: S/MIME Cryptographic Signature ___ 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
Re: [oi-dev] What is the equivalent for GNU ld's --export-dynamic?
> On 25. Mar 2021, at 06:27, cretin1997 via oi-dev > wrote: > > > ‐‐‐ 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. > 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 ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Trouble compiling Juci++ IDE
On Thu, Mar 25, 2021 at 9:09 AM Udo Grabowski (IMK) wrote: > On 25.03.21 07:31, cretin1997 via oi-dev wrote: > > The dependencies of it were listed there: > > > > https://gitlab.com/cppit/jucipp > > > > The problem is there is no gtksourceviewmm-3.0 on OpenIndiana. > > > > No ? Really ? > Yes, really. As stated, gtksourceview is present, but gtksourceviewmm isn't. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Trouble compiling Juci++ IDE
Uh, indeed... On 25.03.21 10:27, Peter Tribble wrote: On Thu, Mar 25, 2021 at 9:09 AM Udo Grabowski (IMK) mailto:udo.grabow...@kit.edu>> wrote: On 25.03.21 07:31, cretin1997 via oi-dev wrote: > The dependencies of it were listed there: > > https://gitlab.com/cppit/jucipp > > The problem is there is no gtksourceviewmm-3.0 on OpenIndiana. > No ? Really ? Yes, really. As stated, gtksourceview is present, but gtksourceviewmm isn't. Uh, indeed... smime.p7s Description: S/MIME Cryptographic Signature ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Trouble compiling Juci++ IDE
SunOS imksunth7 5.11 illumos-cf25223258 i86pc i386 i86pc On 25.03.21 10:09, Udo Grabowski (IMK) wrote: On 25.03.21 07:31, cretin1997 via oi-dev wrote: > The dependencies of it were listed there: > > https://gitlab.com/cppit/jucipp > > The problem is there is no gtksourceviewmm-3.0 on OpenIndiana. > No ? Really ? # s11: uname -a SunOS imksuns11 5.11 oi_151a9 i86pc i386 i86pc ... Wrong machine for uname, should have been: SunOS imksunth7 5.11 illumos-cf25223258 i86pc i386 i86pc smime.p7s Description: S/MIME Cryptographic Signature ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Trouble compiling Juci++ IDE
On 25.03.21 07:31, cretin1997 via oi-dev wrote: > The dependencies of it were listed there: > > https://gitlab.com/cppit/jucipp > > The problem is there is no gtksourceviewmm-3.0 on OpenIndiana. > No ? Really ? # s11: uname -a SunOS imksuns11 5.11 oi_151a9 i86pc i386 i86pc # s11: locate sourceview /usr/include/gtksourceview-2.0 /usr/include/gtksourceview-3.0 /usr/include/gtksourceview-2.0/gtksourceview /usr/include/gtksourceview-2.0/gtksourceview/completion-providers /usr/include/gtksourceview-2.0/gtksourceview/gtksourcebuffer.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourcecompletion.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourcecompletioncontext.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourcecompletioninfo.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourcecompletionitem.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourcecompletionproposal.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourcecompletionprovider.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourcegutter.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourceiter.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourcelanguage.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourcelanguagemanager.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourcemark.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourceprintcompositor.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourcestyle.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourcestylescheme.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourcestyleschememanager.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourceundomanager.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourceview-typebuiltins.h /usr/include/gtksourceview-2.0/gtksourceview/gtksourceview.h /usr/include/gtksourceview-2.0/gtksourceview/completion-providers/words /usr/include/gtksourceview-2.0/gtksourceview/completion-providers/words/gtksourcecompletionwords.h /usr/include/gtksourceview-3.0/gtksourceview /usr/include/gtksourceview-3.0/gtksourceview/completion-providers /usr/include/gtksourceview-3.0/gtksourceview/gtksource.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcebuffer.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcecompletion.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcecompletioncontext.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcecompletioninfo.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcecompletionitem.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcecompletionproposal.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcecompletionprovider.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourceencoding.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcefile.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcefileloader.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcefilesaver.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcegutter.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcegutterrenderer.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcegutterrendererpixbuf.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcegutterrenderertext.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcelanguage.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcelanguagemanager.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcemark.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcemarkattributes.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourceprintcompositor.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcesearchcontext.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcesearchsettings.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcestyle.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcestylescheme.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcestyleschememanager.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourcetypes.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourceundomanager.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourceutils.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourceview-typebuiltins.h /usr/include/gtksourceview-3.0/gtksourceview/gtksourceview.h /usr/include/gtksourceview-3.0/gtksourceview/completion-providers/words /usr/include/gtksourceview-3.0/gtksourceview/completion-providers/words/gtksourcecompletionwords.h /usr/include/pidgin/gtksourceview-marshal.h /usr/lib/libgtksourceview-2.0.so /usr/lib/libgtksourceview-2.0.so.0 /usr/lib/libgtksourceview-2.0.so.0.0.0 /usr/lib/libgtksourceview-3.0.so /usr/lib/libgtksourceview-3.0.so.1 /usr/lib/libgtksourceview-3.0.so.1.3.0 /usr/lib/amd64/libgtksourceview-2.0.so /usr/lib/amd64/libgtksourceview-2.0.so.0 /usr/lib/amd64/libgtksourceview-2.0.so.0.0.0 /usr/lib/amd64/libgtksourceview-3.0.so /usr/lib/amd64/libgtksourceview-3.0.so.1 /usr/lib/amd64/libgtksourceview-3.0.so.1.3.0 /usr/lib/amd64/pkgconfig/gtksourceview-2.0.pc /usr/lib/amd64/pkgconfig/gtksourceview-3.0.pc /usr/lib/meld/meld/util/sourceviewer.py
Re: [oi-dev] What is the equivalent for GNU ld's --export-dynamic?
On 03/25/21 05:27 AM, cretin1997 via oi-dev wrote: 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. Hello! There are several german people that have finally migrated to spain. Amongst them there are several people that do not speak spanish very much, or do it at all. In these cases i ask what are they doing in spain while denying the native language ? Stephan ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
