So here's the rub. linkage on x86_64 with a mix of static and shared libraries and pic and non-pic code is, to me at least, and undefined mess. Again one curses idiot designers, Intel in particular but the Unix folks as well.
Suppose I statically link a program non-pic. That's what Felix does. So I get a copy of, say, the GC. No suppose I link a plugin. The code is pic. But you should note that the plugin is dynamically linked. So it does NOT get a copy of the GC, it expects to load it at run time. Now, Felix is carefully set up so shared library NEVER on pain of death use the executable symbol table. This is an utterly stupid idea which unfortunately many people use, eg Python on Linux does this and it is a disaster. Felix also generates re-entrant code with NO global variables. SO now, when the program loads the plugin and the plugin loads the GC .. we get TWO copies of the code. If we linked the plugins all statically -- but still PIC -- then if we have two plugins we get a copy for the mainline and one for each plugin. I have no idea how PIC and non-PIC code interacts. Certainly non-PIC mainlines can load shared libraries (which have to be PIC). Apply, in recent OS, totally discards non-PIC because of the confusion it causes. In any case, there are hidden globals in C++ and C due to the idiot language designers: stderr is one of them. And it is stderr in the GC called from a plugin that is causing a problem. Whether the idiot linker is capable of handling this I don't know. However a fully dynamic link still fails. Note that stderr works from for hundreds of diagnostics before the failure. The fault is triggered by any print to stderr from flx_gc.cpp, prints in flx_collector.cpp work fine. So I have a test case where I can reliably trigger a segfault in a well defined way that does not appear to be an accident. Of course this is NOT the fault i'm looking for, which occurs with no diagnostics, this is a fault in the diagnostics. There may or may not be a common cause. It's clear, somehow something got corrupted, or the linkage simply screwed up without a diagnostic. [Note on Apple, the C standard library is ALWAYS a shared library, it cannot be statically linked, I think Linux is the same using gcc unless you use really special switches. And fprintf(stderr,"") is entirely a C library call] -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ Is your legacy SCM system holding you back? Join Perforce May 7 to find out: • 3 signs your SCM is hindering your productivity • Requirements for releasing software faster • Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
