On Thu, Sep 1, 2011 at 5:41 PM, grischka <[email protected]> wrote: > Rob Heatherly wrote: >> >> tcc -Wall -Wunsupported -bench -shared -soname libyLOG.so.1 -o >> libyLOG.so.1.0 -lrt yLOG.c >> >> It performs as expected when my main program is compiled with tcc, but >> when that same main program is complied with gcc I get the following >> when linking... >> >> libyLOG.so: file not recognized: File format not recognized >> >> When I recompile the yLOG library with the tcc "-g" flag, the main gcc >> program compiles/links to it with no problem. Small, but maybe >> confusing deal. Am I missing or doing something classically stupid? > > Indeed that looks confusing. I tried this setup with a _very_ > simple foo.so (with only one "hello world" type function) and it > seemed to work finr, regardless of -g. (using a gcc 4.3.2 on an > older ubuntu64 for the main program). > > However I also tried that with libtcc.so as produced with > ./configure --disable-static > and then running the result gave a lot of errors about relocations > out of range and then crashed. Also regardless of -g. > > Which suggests that there might be something wrong with tcc's > shared libraries on x86-64. I can't tell what however. > > One thing to note is that tcc does not support -fPIC while gcc > actually requires it for libtcc.so. Maybe it has to do with > that, maybe not. > > --- grischka
I had seen the fPIC disclaimer previously, but the shared function works so well in mob/git that I had forgotten in my excitement. Also, not killing me, but does this mean that a separate version is loaded for each program that calls the shared library? To add a little to your comment on the "relocations," I get one of three outcomes when using these libraries. Keep in mind that all are related to x86_64 architecture. 1) on my custom crond (compiled in tcc), I call two tcc made shared libraries and perfecto, works like a charm. huge thanks to you guys. 2) on an bigger opengl application, I call four tcc made shared libraries (three with opengl themselves) and it runs, but issues several warnings following the pattern below (but only on some library calls, not all). i simply use gcc on the main program when this happens. no immediate worries. hexworld: Symbol 'yFONT_print' causes overflow in R_X86_64_PC32 relocation 3) finally, the warnings shown in option two can keep the program from running. again, switching to gcc on the main program only solves it. I could absolutely be doing something incorrectly that gcc masked, but I hate gcc protecting me from myself. I'd rather be warned at compile-time and address it. I am committed to migrating to tcc over time and don't mind working around things as it grows -- nothing above is holding me up. Please take this input with the best spirit of commitment to seeing the fascinating product develop... _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
