Re: [Tinycc-devel] minor fixes pushed upstream for RPM packaging

[grischka]

Henry Kroll wrote:
> Well, I was interested in packing this for Fedora and maybe going
> through the process of becoming a maintainer. The Fedora people contend
> that the dynamic linker is "smarter;" however, they discourage rpath.
> http://fedoraproject.org/wiki/PackagingGuidelines#Beware_of_Rpath
>
> The logic goes that because the library is installed in a standard
> location path (/usr/lib, /usr/lib64) an rpath is not necessary.

Makes sense.  Other questions:
    CFLAGS+=-fPIC
    LINK_LIBTCC=-ltcc

1) Why do you need to add -fPIC to general CFLAGS?  Note that it is
already set for libtcc.so.1.0:
  libtcc.so.1.0: CFLAGS+=-fPIC
AFAIK "position independent code" makes sense only for shared libraries.

2) Why do you need to add -ltcc to the linker command?  The
rule to link 'tcc'
    tcc$(EXESUF): tcc.o $(LIBTCC)
        $(CC) -o $@ $^ $(LIBS) $(LINK_LIBTCC)
already has libtcc.so.1.0 on the command line.

Also '-ltcc' would not work unless tcc is already installed which it is
not when you make it for the first time.  If you add '-L.' it would
still not work because libtcc.so does not exist locally.  You could then
link libtcc.so -> libtcc.so.1.0 locally which is what you had before.
But anyway it works out of the box without -ltcc at all.

--- grischka

> ===> For those new to this topic, Fedora hates static libraries and
> wants everything to be shared without rpath, so right now we have this
> configuration:
>
> $ ldd tcc
>         linux-vdso.so.1 =>  (0x00007fffe2fff000)
> ===> libtcc.so.1.0 => /usr/lib64/libtcc.so.1.0 (0x00007f1d37815000)
>         libm.so.6 => /lib64/libm.so.6 (0x0000003063e00000)
>         libdl.so.2 => /lib64/libdl.so.2 (0x0000003064200000)
>         libc.so.6 => /lib64/libc.so.6 (0x0000003063a00000)
>         /lib64/ld-linux-x86-64.so.2 (0x0000003063600000)
>
> This verifies that libtcc.so.1.0 is indeed being picked up by the
> dynamic linker here on my machine and tcc -run is functioning.
>
> $ tcc -run win32/ex*/fib.c 22
> fib(22) = 17711
>
> On Mon, 2010-12-20 at 18:37 +0100, grischka wrote:
> > Henry Kroll wrote:
> > > These include -rpath issues,
> > What are these issues with -rpath, exactly?