The question comes from my problems comes when i add plugins support to LodePaint. LodePaint just use .so plugins , and in main code do such thinks like:
#include <dlfcn.h>
namespace
{
template<typename F>
void do_dlsym(F& functionPointer, void* dl, const char* name) //to avoid warning
"dereferencing type-punned pointer will break
strict-aliasing rulesdereferencing type-punned
pointer will break strict-aliasing rules" when using dlsym
{
//*(void **)(&functionPointer) = dlsym(dl, name); //this gives the warning
union { F func; void* obj; } alias; //Wikipedia's way to avoid the warning!
alias.obj = dlsym(dl, name);
functionPointer = alias.func;
The problem is: When i compile main program (lodepaint) with static linking (without -use-dyndl), then, when i choice plugin it crashes , on libc.so (can provide crash log if its need it).
If i compile main program with -use-dyndl, then everything works fine. But still i curios, why it crashes when main programm are static, and, should it be like that or not.
Maybe need some kind of flags passed to gcc for amiga-specific support or kind ?
For example for linux, the same program compiles statically, and plugins dinamically as should, and all works fine.
Can also provide little example codes, crashlogs and alt if anyone in interest.
Edited by Rigo on 2010/6/13 8:48:03 Edited by Rigo on 2010/6/13 8:49:36
Your plugins need to be compiled with -fPIC, although I don't think this is causing the problem.
Usually crashes like that are due to shared objects linking to static objects. If you are using shared objects at all, it is better to compile everything -use-dynld anyway.
add the -fPIC flag to teh plugin file and however i think you should remove (rename) libstdc++.so and use the static version of library when use c++ files. I've some experience with a bug in libstdc++.so. If you use the static one the version disappear.. I must file a bugzilla entry
Well, shared objects can't be linked to static libraries, so when they try to call something in a static library, they crash as the function is in unallocated memory.
Maybe you need to link your plugins explicitly to libraries they need? If you aren't doing that, it may only be due to being called from an app which has the required shared objects loaded already, that causes them to find them. Link the main executable statically and the shared objects won't be in memory.
Still its strange, becasue on linux it works fine. I mean usage of .so plugins from the main, statically linked, programm. For now i test it like that:
If i add just -use-dynld for the main programm, all works fine. But still i in interst: it is possible somehow make it works when main programm static, or not.
From the PDF on which ssolie point me, i see that is possible, but strange why for me it crashes then (i passed all those -fPIC and -Wl.-export-dynamic flags)
If i add just -use-dynld for the main programm, all works fine. But still i in interst: it is possible somehow make it works when main programm static, or not.
From the PDF on which ssolie point me, i see that is possible, but strange why for me it crashes then (i passed all those -fPIC and -Wl.-export-dynamic flags)
Yes, technically calling shared objects from a static-linked binary is fine. My little libdl archive on Aminet has an example which can be compiled static or -use-dynld and will work both ways.
Check with readelf -d that your .so plugins list libc.so as a required object.
I add stack cookie to each plugin, but still, error the same, and happenes when i close main programm. What can cause such problem ? (and error, always the same, for any plugin, on always the same addresses).
How can i trace where is problem ?
For one plugin that crash happenes when i only run/close main programm with loading plugin. Other plugin crashes when i load programm, open a file, then exit, and then have such crash.
Why i ask about, because looks like when main binary are dinamic, GR cant say you exactly where crash is happenes, and refer just to newlib.kmod only. But when its static - you can see where is crash in programm happenes. But for see that, you need main static binary and your shared plugin , which, you cant link with any .a looks like (so, pluging then make no sense in that terms, just becasue plugins usually done for all those 3d party lib.a which you add to your plugin). But when all is -use-dynld, then all is ok (except that you cant normally detect where is crashes happenes)
For now i just create a plugin without any references to any .a , and then trying to catch error, but, in generall, its bad that i cant see where is crash happenes when main binary is dinamic (or can ? )
I also try to use GDB, but it crashes like hell, and just cant load or attach from GR that main dinamic binary at all.
If you have built libjpeg.so you should upload it somewhere. I could not find it anywhere. It has disappeared from os4depot. And Wesnoth is also linked against libjpeg.so ... :|
1) you must compile all pluginsg with -fPIC gcc -shared -fPIC myplugin.c -o myplugin.so
2) rename (delete..) all your libstdc++.so in the SDK: dir and use the static one. You will have bigger exe but that works correctly
3) if you are using pluginst that use internally OS4 functions and so they need IExec/IDOS and so on interfaces opened with -lauto on main exe you MUST use -Wl,--export-dynamic into the .exe
4) if a simply plugin crash the problem is not surely a stack but there si a problem somewhere. use always -gstabs when compile and use addr2line to track the last valid function that is called before newlib/elf and so on
5) when possible link also dependecies with your plugin. so if your plugine needs f.e. libpng compile it with
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
