Since I already started working on an updated RTTR (Settlers 2.5) port for MOS, it made sense to make it my first OS4 port. The game is built like this: main executable, video plugin, audio plugin. The two plugins use SDL to handle the sound, input, GL context creation, etc. The problem is when I try to open them with dlopen() they crash. Here's stacktrace: Quote:
As you can see _INIT_CreateInput() crashes, which is one of the SDL constructors: http://code.google.com/p/os4sdl/sourc ... gaos4/SDL_os4wm.c?r=38#62 My question is, can I use SDL from SObjs? BTW, I'm using the static libdl.a from os4depot for convenience, so the main executable is linked statically.
This is just like television, only you can see much further.
BTW, I'm using the static libdl.a from os4depot for convenience, so the main executable is linked statically.
You must link the entire thing dynamically to use sobjs with dlopen(). Whichever version you use.
There is also a libdl.so in SOBJS: I believe, which you can link inot you SDK:Local/newlib/lib drawer is not allready done.
You should link the main executable with
-ldl -lauto -use-dynld
You should build the plugins with -fPIC and link with
-shared.
You *must not* build the main excutable objects with -fPIC. ( A mistake I made during blender porting that wasted a lot of time!).
If the plugin depends on code in the main executabe then you'll likely need
-W,l--export-dynamic
when linking the main executable so as to make symbols (functions and data) visible to the plugins. (not sure how many -- that option takes might be -export or --export).
ADVANCED:
You can link static libraries into dynamic executables but there a lot of pit falls, particularly if any external plugins or sobj type libraries depend on their code.
libdl.a should be okay as it's unlikely that a plugin will load other plugins, and even if they do the relevant symbols are likely already included into the executable from the library.
@broadblues It looks like I got almost everything right (using -fPIC only on the plugins, etc.). I only used the static libdl.a, because for some reason with -use-dynld the executable go linked with libbz2.so.1.0 instead of libbz2.so. So thanks, I'll try libdl.so, and get back to you.
This is just like television, only you can see much further.
I have libbz2.so.1.0.4 and its link libbz2.so in sobsj: and in the sdk drawer. I could make a libbz2.so.1.0 link, but then everyone else who has the newer sobj would have to do the same... that's not really good, I'd prefer to link agains libbz2.so.
This is just like television, only you can see much further.
I could make a libbz2.so.1.0 link, but then everyone else who has the newer sobj would have to do the same... that's not really good, I'd prefer to link agains libbz2.so.
I agree it's not an ideal way to work it, but it is the standard way to work it at this time. So anyone installing the newer sobj should have made those links. So you don't need to worry about the software not running due a missing link on the users machine.
[edit] Ideally an installer script (for the sobj not the application) should make the links for the user [/edit]
@broadblues I think ideally the program should be linked against libbz2.so. Anyways, I made a libbz2.so.1.0 softlink, the game started up, and crashes the same way it did with the static version of libdl.so
This is just like television, only you can see much further.
If you need to build something against a different version of an sobjs available in the OS4.1 install, simply add an sobjs/ subdir in your programs dir and add your special sobjs in there.
AmigaOS4.1 will first look and use sobjs in the programs main dir (if available) and only after that pick the ones from the system.
A great way to not clutter users SOBJS: with add-on .so's aswell
People are dying. Entire ecosystems are collapsing. We are in the beginning of a mass extinction. And all you can talk about is money and fairytales of eternal economic growth. How dare you! – Greta Thunberg
@Raziel So far I'm only using stock sobjs, but I'll keep that in mind.
edit: In the end I went for linking the plugins to the executable, like I did with the previous version. This way the SDL constructors don't crash anymore, but unfortunately the game eats up my 512MB memory in no time... darn!
Edited by BSzili on 2013/11/22 15:44:32
This is just like television, only you can see much further.
I can see from that that IExec isn't initilised and is still 0 so that the first call to AlloCSysObjectsTags causes a DSI (which if ignored would ISI)
Not sure why this would be, and why it's not using the main executables IExec, it may be that your plugin needs to intialise IExec in a higher priority constructor. But this would normally allready be done for a main executable.
Did you link your main executable against SDL ? That would call the constructors from the main program so that IExec was allready initialised by the startup code. Ofcourse that means loading the SDL sobj whether or not you need the plugin, which is counter productive.
Quote:
edit: In the end I went for linking the plugins to the executable, like I did with the previous version. This way the SDL constructors don't crash anymore, but unfortunately the game eats up my 512MB memory in no time... darn!
How big is this game? Are the plugins always required? In which static verses dynamic won't make much difference anyway.
@broadblues The the plugins are small, but main executable is pretty big, around ~100MB including the debug symbols. I can live with the statically linked plugins, I just wanted to remove my hacks to emulate the symbol query, avoid namespace clashes, etc. I didn't link the executable against SDL, because it doesn't use SDL at all. Maybe I'll try that later.
This is just like television, only you can see much further.
Does this use SDL_LoadObject at all? I don't think that's implemented in our SDL. I use shared objects on occasion, but without dlopen which I have no experience with.
Edit: Just noticed you said it doesn't need SDL. Still, it's worth mentioning that SDL_LoadObject isn't available... yet.
@MickJT RTTR uses a plugin system. The main executable doesn't use SDL, only the audio/video plugins do. I tried both the stock libdl.so, and the static libdl.a to load them (dlopen()) to no avail. I fixed this by statically linking the plugins to the executable.
This is just like television, only you can see much further.
I think the fly in the ointment here is the way the SDL constructors assume that IExec is available and initialised.
I'm currently re-porting perl to newlib using shared objects for the perl modules (as opposed to the horrid hacks need for the old clib version). Once I've got the main perl distribution stabilised, I'll revisit perl_SDL and see if I get the same type of issues, if I do then SDL may require fixing.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
