[Top][All Lists]

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

Re: [Tinycc-devel] configury (was const_wanted)

From: Thomas Preud'homme
Subject: Re: [Tinycc-devel] configury (was const_wanted)
Date: Mon, 8 Aug 2011 15:13:35 +0200
User-agent: KMail/1.13.7 (Linux/2.6.39-2-amd64; KDE/4.6.5; x86_64; ; )

Le dimanche 7 août 2011 21:38:44, grischka a écrit :
> Thomas Preud'homme wrote:
> >> Anyway I pushed some patches so you can have crtprefix1:crtprefix2.
> >> Note that it's also sysrooted.  I don't know why you changed that.
> > 
> > Did I? When? I was probably not careful enough.
> No, it seems you wanted to fix something.  It's just not
> clear what:
>      http://repo.or.cz/w/tinycc.git/commitdiff/5e954fe
Oh, I'd definitely too picky. In CONFIG_TCC_LIBPATH all the lines looked like 
CONFIG_SYSROOT sthg except the first one which was just CONFIG_TCC_CRT_PREFIX. 
Hence I wanted to extract the SYSROOT from the CRT PREFIX. I should really be 
suspicious about any pickyness which I might feel.
> > I've looked your commit quickly but I mostly notice the "Oh Deer!" in the
> > commit message. I may have insisted too much on it. It's indeed a bit
> > more annoying but I already sorted out the correct dependency to work
> > without this in the next upload.
> That comment was not about you at all.  It is about gcc, a compiler
> which as we know can solve any problem, even those of distros with
> packaging.

Or maybe gcc is just getting prepare for future version of the FHS. The 
rationale behind multiarch is already endorsed in the current FHS in the more 
specific case of 32bits / 64bits libraries [0].

I believe what is done in Debian is just a generalisation of this to be able 
to coinstall a library for many architecture at the same time. Think about the 
simplification for cross-compilation for example, the sysroot become useless. 
And if I remember correctly some similar work are being done in other major 
distribution so a consensus [1] shall be achieved one day or another and 
written down in the FHS when it'll happen.

So if the file system layout change it's quite normal that gcc have to handle 
these changes. The only thing which could be reproached to gcc is to integrate 
the changes prematurely.

[0] http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64
[1] I heard the triplet name used are not the same in the different approaches. 
I know, it makes a lot of "IIRC, I heard, etc…"
> > So I'm very pleased to have this commit but if it really annoys you then
> > revert it.
> There is no reason for me to revert the commit even if you now decide
> that you don't need it because if not anything else it still makes
> tinycc 6 lines tinier.
>      $ git log --stat
>      commit e844fb11c25293ba346a3470fa4ca33184770538
>      libtcc: support more than one crtprefix
>      [...]
>      5 files changed, 39 insertions(+), 45 deletions(-)
Fine. I have no interest in arguing anyway, I'm very happy with this :)
> > Anyway, thanks again for your work. I'm happy to see I'll be able to drop
> > all the patches currently in Debian.
> Btw, does 'i386-tcc hello.c' work on your x86_64 system?
Well, almost. I had to do 2 things. First, as each architecture has its own 
multiarch triplet(it's the whole point of multiarch actually), I had to rerun 
the configure (one configure for each (cross-)compiler. Which gives something 

./configure --prefix=/home/robotux/local --
\\\\\\\\b/include/i386-linux-gnu:\\\\\\\\b/include" --libpaths=/usr/lib/i386-
gnu:/usr/local/lib" --crtprefix="/usr/lib/i386-linux-gnu:/usr/lib"

Of course with simple quote the number of backslash is divided by two but then 
I loose the variable substitution I use for the multiarch triplet.

Second and more important, I had to do a symlink from sysroot/lib/tcc/i386 to 

After that (and of course installing the 32 bits libraries), everything worked 
as expected. I could compile a simple test.c file and execute it.
> Thanks,
> --- grischka

Best regards,

Thomas Preud'homme

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

reply via email to

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