Shared objects and libauto

Is it possible to use -lauto when building a shared object? If so, how is the correct way to do so?

This is my shared object code:

*******
#include <proto/dos.h>

int printhello()
{
IDOS->Printf ("Hello world!\n");
return (0);
}
*********
and the main code:
*********
extern int printhello();

main()
{
printhello();
}
**********


and this is the makefile:

gcc -shared -Wl,--no-undefined myso.c -o libmyso.so -lauto
gcc -use-dynld -o mytest mymain.c -L. -lmyso -lauto


As you will see, the linker gives errors like "undefined reference to IDOS" etc.

I have tried without -Wl,--no-undefined, and it does seem to work this way. Only problem is, I need to keep this flag on for other reasons! Help!?

@alfkil

Unless you have a libauto.so, I would say no. Open all libraries/interfaces manually and dispense with it.

@Chris

Damn... That sucks

@alfkil

Quote:No, you must not link any static link library into a shared object. That doesn't work and will crash.
(Unless all code in the static link library was compiled with -fPIC, but libauto.a isn't.)

A libauto.so wouldn't make much sense since it would always open all supported libraries, classes, devices, etc., not only the required ones.

Quote:You have to add -fPIC (for compiling if you do it seperately) and remove -lauto.

Quote:IDOS isn't opend by libauto anyway but by the C library startup code (currently IExec, IDOS, IUtility, SysBase, DOSBase and UtilityBase).

Quote:For what do you need --no-undefined? Using it in a shared object doesn't make sense to me.
If you have to keep using --no-undefined I guess the only way is to open IDOS, but using another variable name, yourself in a constructor function in your shared object and close it again in a destructor function.

@joerg

Thanks for the clear up! I'll see what I can do from here...

One comment: The reason for using -Wl,--no-undefined is, that otherwise ld won't tell me of any missing dependancies when building the shared library, which is just very impractical...

@alfkil

if you use -Wl,--export-dynamic when you link your exe with -lauto you will solve the problem

@afxgroup
Quote:
Can you please explain exactly why this solves the problem?

If libauto.a or any other static library is not compiled with -fPIC I don't see how it solves anything.

@ssolie

because the exe is linked with libauto. and -Wl,--export-dynamic will export IDOS, IExec and so on.
I had the same problem with iODBC when i was trying to load sqlite.so that needs IExec adn IDOS to be opened. Without that switch i was getting a DSI since no one was exporting the interfaces pointers and neither sqlite opens it. Using that switch in the main exe allow the shared objects to gain also its shared variables.
It is tested. i've spent two weeks to understand why the sqlite.so was crashing when loaded. After adding that switch and without adding any line of code all is fixed..

@afxgroup

Nice

@ssolie

Quote:He can't because it doesn't

He is using --export-dynamic for something completely different and unrelated to the problems caused by linking the shared object with --no-undefined ("Strange gcc problem" thread in the OS4-invite mailing list).

@joerg

sorry,
i didn't read that he has undefined references to IDOS in the lib
So just add

struct DOSIFace *IDOS;

in the lib and it works

http://www.amigasoft.net/test/hello.lha.lzh

a complete example

@afxgroup

I'm a bit confused about how this really works: IDOS is already defined in the startup module, so how does it help me to redefine it in the library? Won't this just cause mixed references??

Anyways, your example seems to work, I'm just confused about how

@alfkil
Quote:
Doesn't look like it is worth the risk to me. The rule is to not link anything that isn't compatible (i.e. compiled with -fPIC) and libauto.a is not compiled with -fPIC.

Undefined behaviour territory is never a nice place to be when you are codin'