[oi-dev] What is the equivalent for GNU ld's --export-dynamic?

[Toomas Soome]

> On 25. Mar 2021, at 06:27, cretin1997 via oi-dev <oi-dev at openindiana.org> wrote:
> 
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, March 25, 2021 1:43 AM, Bob Friesenhahn <bfriesen at simple.dallas.tx.us> 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
>> bfriesen at 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 at 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