[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Tinycc-devel] const_wanted

From: Thomas Preud'homme
Subject: Re: [Tinycc-devel] const_wanted
Date: Tue, 2 Aug 2011 00:58:00 +0200
User-agent: KMail/1.13.7 (Linux/3.0.0-1-amd64; KDE/4.6.5; x86_64; ; )

Le lundi 1 août 2011 19:22:19, grischka a écrit :
> Thomas Preud'homme wrote:
> > Solution 1:
> Yes.  Good luck ;)

Done (see 76adc57). I have a "solution" for the elf_interpreter in Debian but 
it's more invasive (~10 lines of code added) and only suited for native 
compilers (which is fine in Debian since only native tcc is packaged). But it 
doesn't allow to generate a program for a system non multiarch if tcc is on a 
multiarch system (or the reverse), which is more annoying. Anyway, I attached 
it in case you're curious and just to make you cry ;-)

Note that it would be better to use tcc_add_file_noerror for libgcc_s.so.1 and 
crtn.o as well but we'd need to be able to not export the symbol in libtcc.a. 
A file included in both libtcc.c and tccelf.c containing this function would do 
it but I thought it would be overkill.

So about elf_interp, I wanted to support both path but of course it's 
impossible. What is different from the other paths is that it's about the 
compiled programs, not about tcc. Hence, even if tcc is compiled for a 
multiarchified system, we want to be able to generate code either for a 
multiarch system or not. Maybe a new switch is necessary for tcc? Or worse, we 
could consider doing two tcc for each system, one which generate a multiarch 
elf interpreter, one which generate a simple elf interpreter. This way, 
however multiarch or not is tcc, we can generate multiarch aware programs or 

I really need suggestion for this :)
> --- grischka

Attachment: multiarch.patch
Description: Text Data

Attachment: signature.asc
Description: This is a digitally signed message part.

reply via email to

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