[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] tcc shared libraries with gcc programs
From: |
Rob Heatherly |
Subject: |
Re: [Tinycc-devel] tcc shared libraries with gcc programs |
Date: |
Fri, 2 Sep 2011 00:45:15 -0700 |
On Thu, Sep 1, 2011 at 5:41 PM, grischka <address@hidden> 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...