[Top][All Lists]

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

Re: [Tinycc-devel] Include path bug (Was: Re: plans to 0.9.27)

From: avih
Subject: Re: [Tinycc-devel] Include path bug (Was: Re: plans to 0.9.27)
Date: Fri, 13 Oct 2017 21:04:17 +0000 (UTC)


Could you be specific about your setup and what exactly fails?

I also use Alpine linux (edge) x86_64, obviously no glibc, and with the recent changes - tcc seems to work very nicely for me.

Excuse the possibly obvious steps below, but to hopefully get to the point quicker, here's what works for me:

Let's start with building tcc itself. This should get you going from scratch (assuming you have the devel packages for the docs etc):

cd ~ && git clone git://repo.or.cz/tinycc tcc-src && cd tcc-src &&
  mkdir bld && cd bld &&
  ../configure --config-musl --with-selinux --prefix=$(pwd)/dist &&
  make -j8 && make test && make install

Assuming it succeeded the build and tests, and installed to ~/tcc-src/bld/dist, let's
symlink the executable at nice global place:

sudo ln -s $(pwd)/dist/bin/tcc /usr/local/bin/tcc

Now you should have a working global 'tcc'.

For me, it compiles simple programs without much ado, simply 'tcc test.c',
including ones which use stdarg, whether #include <stdarg.h> comes before
or after #include <stdio.h>  , and the programs run as expected.

Now to build something bigger. Let's take tmux, which also uses stdarg:

cd ~ && git clone https://github.com/tmux/tmux.git tmux-src && cd tmux-src &&
./autogen.sh && CC=tcc ./configure && make -j8

And if you feel like installing it globally, do also sudo make install. I did.

Whether I built tcc while booted with the hardened or vanilla kernel, and whether I ran tumx while booted with either kernel - it seems to work.

So on the face of it, I don't see most of the issues which tcc had in the past with musl/alpine.

On Friday, October 13, 2017 11:04 PM, Steffen Nurpmeso <address@hidden> wrote:

grischka <address@hidden> wrote:
|Steffen Nurpmeso wrote:
|> mildly.  I guess the right thing to do would be to strip all paths
|> which are also in the system array from the user paths present in
|> the non-standardized $C_INCLUDE_PATH environment variable, even if
|> that means that this possibly changes the search order desired by
|> the user anyway. 
|Not quite.  Really the only thing you can do is to clean up that
|suspicions system path cruft from the C_INCLUDE_PATH on YOUR OWN

I see no reason to start screaming.  If that would have been the
first reply of yours i would have looked around earlier for sure.
I think it was clear that i have no idea of compiler internals.

|    - /usr/local/include
|    - /usr/include
|Search order is fixed by conventions, and the built-in system
|paths have least priority.
|This implies that it is the compiler's business to set them and
|that at the same time the user is allowed to override them, even
|if then the compiler stops to work at all.
|Therefor your C_INCLUDE_PATH cannot work for tinycc.
|(The public version of tinycc that is, and as long as it needs
|its own stdarg.h / does not have __builtin_va_stuff)

I have recreated my patch locally, because i need tcc for working.
I do not know whether gcc and pcc create __builtin sauce in code,
but they do the right thing here, regardless of my C_INCLUDE_PATH.
gcc does not read its own stdarg.h, therefore i would assume it.
tcc also works like this on GNU LibC systems, by the way.

But hey, the bug has been reported, a simple-minded patch has been
rejected, i am eagerly awaiting a true fix.

Ciao.  And have a nice weekend, of course.

|Der Kragenbaer,                The moon bear,
|der holt sich munter          he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Tinycc-devel mailing list

reply via email to

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