[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tinycc-devel] going nuts trying to get / generate windows binary of
Re: [Tinycc-devel] going nuts trying to get / generate windows binary of tcc[Scanned]
Wed, 15 Feb 2006 21:20:50 -0500
On Wed, Feb 15, 2006 at 11:16:53AM -0500, Ben Hinkle wrote:
> On 2/14/06, Andrew Finney <address@hidden> wrote:
> I put all my mingw-related work in directories without spaces (eg /c/mingw,
> /c/tcc etc). I have no idea if that would solve the problems you are seeing
> but in a unixy world I never trust that all the tools work with directories
> with spaces.
It's possible. Back when it was still called Interix, even Services
for Unix didn't work right if you installed it under Program\ Files.
> > In file included from tcc.c:51:
> > elf.h:37: error: conflicting types for 'uint32_t'
> > /usr/include/stdint.h:28: error: previous declaration of 'uint32_t' was
> > here
Looking at the code, elf.h assumes that when WIN32 is set, the
compiler will not supply some standard C99 types such as uint32_t.
This looks like an attempt to fix a known problem with MSVC's C99
compliance. MinGW/gcc probably does provide these types, which is
causing a conflict.
> > tcc.c:1338: warning: implicit declaration of function `_vsnprintf'
> > tcc.c:3374: warning: implicit declaration of function `strtold'
> > tcc.c:4026: warning: implicit declaration of function `_snprintf'
There's a bunch of things in tcc.c controlled by the WIN32 setting
that would affect these. I notice that _vsnprintf is a documented
(though deprecated) function over at MSDN. A library suite like MinGW
probably supplies a working vsnprintf and shouldn't use the special
I suspect the basic problem is that when WIN32 is defined, the tcc
code expects to be compiled with MSVC, not gcc. And when WIN32 is not
defined, tcc expects to be able to use ucontext, which is a Unix thing
that MinGW does not provide.
If you want to use something like MinGW, Cygwin, or SFU to compile it,
you're probably going to have to either edit the WIN32 stuff so that
the MSVC parts don't kick in; or leave WIN32 undefined and remove the
ucontext dependency. Last year someone mentioned some success with
the second approach, but had not completely tested it: