Re: [Tinycc-devel] tcc-0.9.24 release soon

[Rob Landley]

On Thursday 06 March 2008 03:52:54 KHMan wrote:
> Hanzac Chen wrote:
> > Win32 binaries with Win32 Api definitely needed.
> > The libtcc.a and libtcc.h for dynamically compilation.
>
> Speaking as a list member, I'll all for more services for users,
> but let's be realistic: I don't think this community has the
> resources to maintain binary releases. We have postings with
> hardly any replies. We are severely resource-constrained.
>
> Note that nobody has responded to grischka's _actual_ topic of
> discussion after over 48 hours. Can this community maintain and
> support binary releases? Binary releases calls for certain
> expectations from their uses.

I didn't reply because it would be off-topic here, but I finally sat down 
yesterday to finish the options.c breakup over in my tree, and I plan to put 
out a release in the next week or so.

I'm currently debugging why arm linking isn't working properly (I can build a 
hello.o with tinycc and then link it with an armv5l-gcc I have lying around, 
but if it links itself the result immediately segfaults under qemu-arm.  
Doing armv5l-objdump on the two results in _huge_ differences and I suspect 
my next step is to build an armv5l-gdb...)  I'm also plotting out what's 
involved in building a libtinyccrt-arm.a (so I don't have to use libgcc.a) 
but that might not make it into this release.

I need to take one more pass at fixing the warnings, although this is _fix_ 
rather than just "suppress with a typecast".  The "signedness of char 
mismatch" warnings are waiting until I can fix the code so it builds 
with -funsigned-char (that way it's naturally 8 bit clean).  Currently if you 
build it with that, the result doesn't work.  And the "cast to pointer from 
integer of different size" warnings (when I build on an x86-64 host) mostly 
have to do with things like sym->next really being a _target_ pointer and all 
the targets currently being 32 bits.

I also need to automate multi-platform regression testing.  If the output that 
tcc is building can run under qemu, then it should be possible to use a 
combination of gcc cross compilers and qemu to run the test suite on each 
supported target platform.  (I've done this by hand but haven't scripted it 
yet.)

I've bumped all the half-finished new features (like variable length arrays) 
to after the release, along with the bug fixes for things that were already 
broken this time last year and thus aren't actually _regressions_.

I mention this because I'm one guy, who already has two other higher priority 
projects (http://landley.net/code/toybox and 
http://landley.net/code/firmware).  I also don't have nearly as much 
understanding of the guts of this code as I'd like, and 90% of the time I do 
find to bang on it is spent reading the existing code, scratching my head, 
and maybe refactoring it.  (And looking up what various assembly constructs 
do, frowning at the objdump -d output, adding the new "-v -v -v" option so 
it's doing a lot of printf() calls to tell me what paths it searched looking 
for what library to link, etc.  I'm still in _way_ over my head.)

Despite this, the vast majority of the changes that went into cvs since I 
left, and thus in the proposed release, were moving old commits from my tree 
into cvs.

I'm not sure "lack of resources" is quite the problem.  I have a lack of 
resources in spades over here, from lack of time to lack of expertise.  There 
seems to be a certain amount of lack of _interest_ involved in the old cvs, 
too.

> IMHO, those who wish to utilize tcc actively should be challenged
> to jump over this barrier of "getting the sources compiled". If
> say P encounters a bug, at least P can help report or fix the bug
> and refresh the sources via CVS or hg and then recompile.
>
> Can someone can put forward a strong case for releasing regular
> Win32 binaries?

Well, in my case I finally got a mingw build environment to run under wine, so 
I may actually _care_ about Win32 again.  (It comes right after arm on my 
todo list, which came after i386.  I may start caring about c67 if anybody 
ever tells me what it _is_, but fourth on my list is adding an x86-64 output 
target.  And then fifth would be either PPC or mips.  Yes, adding more 32 bit 
targets would be _easier_, but not more _useful_. :)

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.