tinycc-devel
[Top][All Lists]
Advanced

[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...



reply via email to

[Prev in Thread] Current Thread [Next in Thread]