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

[Chris]

On 2021-03-24 21:27, cretin1997 via oi-dev 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.

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