mov0xfffc(%ebp),%ebx
4c: dd 03 fldl (%ebx)
It should never use %ebx. Hope this helps.
--- grischka
Regards
Andreas Eriksson
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
(pi.dwProcessId);
which is declared as
VOID ExitProcess(UINT uExitCode);
(and actually never returns).
Anyone wants to fix that?
--- grischka
#include windows.h
#include stdio.h
int main(void) {
int retCode = 0;
PROCESS_INFORMATION pi;/* filled in by CreateProcess
.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
__TINYC__
long long s = ((long long(*)(IplImage*))cvGetSize)(img);
IplImage* gray = ((IplImage*(*)(long long, int, int))cvCreateImage)( s,
8, 1 );
#else
IplImage* gray = cvCreateImage( cvGetSize(img), 8, 1 );
#endif
--- grischka
not to cause other problems.
- (... more stuff you already know).
Next release (0.9.26) is overdue but not urgent.
Thanks,
--- grischka
Best Regards,
Andrew
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo
compilers overly relying on architecture type sizes.
The address bits need to be defined for the target platform. uint##_t
or uintptr_t don't do that. (My mistake to mention that at all.)
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel
_WIN32 (defined _WIN64) == (defined TCC_TARGET_X86_64)
#define TCC_IS_NATIVE
#endif
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
grischka wrote:
For a cross-compiler there are no proper fixes for tccrun. Properly,
everything related to tccrun should be omitted unless it is a native
compiler.
I pushed an attempt:
http://repo.or.cz/w/tinycc.git/commitdiff/a35b3059bb05965022ad317aaba27e22f148
--- grischka
Thomas Preud'homme wrote:
I would be very grateful if anyone with more knowledge than me could do it.
Anyway before we forget I pushed something.
http://repo.or.cz/w/tinycc.git/commitdiff/ae191c3a619db25e3c9d4b6c89d1a9970563d825
Thanks,
--- grischka
= TOK_CDOUBLE;
tokc.d = strtod(token_buf, NULL);
#else
tok = TOK_CLDOUBLE;
tokc.ld = strtold(token_buf, NULL);
#endif
Have Fun ;)
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
,
such as
-Wl,-rpath=stuff
???
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
open
shared object file: No such file or directory
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Thomas Preud'homme wrote:
$ tcc libtcc.c -DONE_SOURCE -shared -o libtcc.so -ldl
I had to add -DTCC_IS_NATIVE
Because you missed -DTCC_TARGET_X86_64 ;)
Btw, for general purpose dynamically grown strings, try
CString linker_arg;
--- grischka
* argument(s) then.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
be careful with your precious (spring-)time ;)
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
/ae191c3a619db25e3c9d4b6c89d1a9970563d825
--- grischka
This snipped of code:
void f(double *a, double *b, void *c)
{
a[0]*abs(3);
}
generates following object code:
0: 55 push %rbp
1: 48 89 e5mov%rsp,%rbp
4: 48 81 ec 20 00 00 00sub$0x20,%rsp
b: 48
tcc_relocate:
- run the ccde
- get symbol addresses
There is one thing you cannot do _before_ tcc_relocate:
- create another TCCState
Also, tcc_relocate can be called only once for each state.
--- grischka
David Mertens wrote:
Milutin, all -
Yes, you were absolutely correct. Once I recompiled
to this story, also:
http://repo.or.cz/w/tinycc.git/commitdiff/4274c44de7dfb99a1058a5af515e9865cc9d2ff9
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
fun,
Michael.
It was fun to read, indeed.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
feature'.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
installs tcc elsewhere
but really we should not care. After all the examples are
for studying purposes in the first place.
--- grischka
[2] cb2138f8b098feb1b51a407343a4b99e25d5b506
Best regards,
Thomas Preud'homme
___
Tinycc-devel mailing list
Tinycc
Michael Matz wrote:
Hi,
On Thu, 10 May 2012, grischka wrote:
[1] See commit 27a428cd0fae475d7377e1dbe218c064ee217d85
Basically /usr/bin/env tcc -run will try to find tcc -run which is
then obviously not found. Should we go back to the solution proposed
in [2] or do you have another idea
-in with
compilers other than GCC.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
grischka wrote:
I tend to agree here with what Christian Jullien wrote:
I’m however against any C extensions that has no roots in C standard.
[...]
I wouldn't however mind at all an extension to TinyCC that allows to
add language extensions as some sort of plugins. If someone wants
even
bother to port.
I don't know enough about that to have an opinion. If it is easy
to add and you think that TinyCC wants that then add it. If it
is extra work and TinyCC can well live without, then don't.
Was this useful? ;)
--- grischka
://sourceware.org/bugzilla/show_bug.cgi?id=14188
If that works may I suggest also to try to get rid of the define
__REDIRECT() uglinesses in TinyCC? ;)
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman
such macro built-in predefined? Not even GCC has it:
$ echo __REDIRECT_NTH(a,b,c); | gcc -E -
# 1 stdin
# 1 built-in
# 1 command-line
# 1 stdin
__REDIRECT_NTH(a,b,c);
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
... )
(That's what I suspected ...)
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Sean Conner wrote:
It was thus said that the Great grischka once stated:
Sean Conner wrote:
As to the patch I think that
+s1-runtime_mem = NULL;
would break tcc_relocate and I don't see why you need it.
I did that so that the call to tcc_delete() wouldn't crash when it tried
to free s
Sean Conner wrote:
But again, how is what I did a memory leak?
The statement
s1-runtime_mem = NULL;
in tcc_relocate_ex would discard the previous value.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
Sean Conner wrote:
Hmmm ... I can see where that appears to be the case, but I did run
valgrind and it reported no memory leaks.
You see nothing. Try valgrind with ./tcc -run examples/ex1.c
--- grischka
___
Tinycc-devel mailing list
Tinycc
the libtcc API.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
still decide.
--- grischka
If you're going to use that method, then I'd suggest this definition
of TCC_RELOCATE_AUTO:
#define TCC_RELOCATE_AUTO (void*)tcc_relocate
If I recall the C standard correctly, that will result on a value
that's unique from all other valid addresses even on Harvard
.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
this
void *tcc_relocate(TCCState *s1, void *(*alloc_fn)(size_t, void*), void
*up);
which looks complicated and since you can't pass just malloc, also makes
things complicated. So I decided for the two step approach.
--- grischka
___
Tinycc-devel mailing
it returns 0 on success and -1 on an error.
Still no. It returns (error ? -1 : ptr == NULL ? size : 0);
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
with it and you can live with it, at least.
http://repo.or.cz/w/tinycc.git/commitdiff/ca38792df17fc5c8d2bb6757c512101610420f1e
Thanks,
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc
If you think it's okay and don't get responses, you might just give
it a try and push on mob. Read more at
http://repo.or.cz/w/tinycc.git
Thanks,
--- grischka
Guillaume Chéreau wrote:
Hello,
I found an issue with tcc.
when trying to compile a code like this one:
struct
bugs in big programs can be (very) difficult.
tcc produces only basic debug info (symbols + line number) and
depending on system/gdb version it might not work at all.
- Preprocess only: tcc -E [-o outputfile] ...
--- grischka
Now then, I used wine-1.5.12 (recent development snapshot
Oleg N. Cher wrote:
Maybe there is a way in TCC to put fucntion Unused to a library, and it
be linked to the target EXE/DLL, if only need?
Sure. Linking as needed is the point of libraries in C and it works
with TCC like with any other C compiler.
--- grischka
Thomas Preud'homme wrote:
Le jeudi 11 octobre 2012 17:06:44, grischka a écrit :
Oleg N. Cher wrote:
Maybe there is a way in TCC to put fucntion Unused to a library, and it
be linked to the target EXE/DLL, if only need?
Sure. Linking as needed is the point of libraries in C and it works
Thomas Preud'homme wrote:
Greetings grischka,
Number of bugs in savannah bug tracking system is increasing without them
being triaged. I recently took a quick look at the list of bugs and found 4 of
them which could be close because they are already fixed:
#13213 cannot use integer
/memberlist.php?group=tinycc
(Btw, Savannah now actually wants passwords with character classes).
Thanks,
--- grischka
Regards,
Thomas
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
0x5af(%rip),%r11# 0x75645f36
0x75645987: mov(%r11),%r11
0x7564598a: callq *%r11
when the code come to 0x7564598a, it's codedump with SIGSEGV.
the ASM CODE 0x5af is wrong!
How is it wrong?
Also, what OS, what TCC version?
--- grischka
with TCC. GCC/Clang pack the bit fields on
the smaller type available. So, sizeof(struct mystruct1) = 4 with
GCC/Clang and sizeof(struct mystruct1) = 8 with TCC.
I tried your bitfield.c test with GCC and it failed on the 2nd
assertion. Hm ...
--- grischka
My program (and probably many others
version checks in one single place
(i.e. configure).
Also, instead of abstract
GCCGREATERTHEN44
(btw. it's greater th_A_n) maybe just call it
GCC_SUPPORTS_W_USUSED_RESULT
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
if sym_index were always
greater by one than the previously passed.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
get_sym_attribute(s1, sym_index)-got_offset = s1-got-data_offset;
Anyway, just my 2 cents of completely untested suggestions. ;)
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
? Note that not just GCC and TCC might be used to compile
tcc. (E.g. more recent MS compilers from the VCExpress editions used
to work)
Thanks,
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo
additional attributes usually. Then again
global symbols always have an associated Elf entry. So maybe this
'struct sym_attr' can be the solution to this problem.
Also, the recently added 'sym-asm_label' looks like a candidate
for being moved from Sym to sym_attr.
--- grischka
the extra weaktest since it is in
tcctest.c also.
So I'd vote to step back to just
TESTS = test3 libtest
which would get rid of filter-out's, lots of the ugly := operators
and most platform trouble at the same time. Just my 2 cents... ;)
--- grischka
Thomas Preud'homme wrote:
Grischka, what do you think of releasing a rc1 after that? We got plenty of
features merged since last release and 3 years start to be quite a long time.
I know there is still many things to improve, including some I care about, but
it might attract new contributions
Kirill Smelkov wrote:
Also grischka writes:
btest is not a feature that we can't recommend to use
really (at least as long as tcc -btest tcc.c doesn't produce anything
useful),
FYI, as of mob a55ecf6d it now does, so please don't treat -b mode as
second class citizen anymore.
Ok. I admit
think I would like to change that just for bcheck. Then again
if that were allowed, the vtop stuff in TCC could stay as it was, I
suppose?
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo
, and also to show typical usage of the
feature with some commands example, for example.
Thanks,
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
want to revamp our tiny testsuite per se, for example
split the tcctest.c mess into single tests (or theme related chunks)
and/or integrate that with the (by someone recently added) tests2 stuff
then I'll certainly not object to that. ;=)
--- grischka
got distracted.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
-devel/2012-12/msg6.html
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
/5ebc6a964d49ebab862f3d006a28162c84644247
http://repo.or.cz/w/tinycc.git/commitdiff/b17439934091744afd0bc42ceefcc712f2fc2434
Apropos release, I'd agree though that a new release can well wait for
a new year. ;)
Thanks,
--- grischka
___
Tinycc-devel mailing list
problem which is not duplicate -I's by the user
but the very obviously crappy handling of #include_next itself. Of course
the patch fixes something, but if we keep it chances are that we'll never see
a correct solution.
--- grischka
___
Tinycc-devel
grischka wrote:
- http://repo.or.cz/w/tinycc.git/commitdiff/3d409b08893873b917ccb8c34398bc41a4e84d7c
The patch doesn't fix the real problem which is not duplicate -I's by
the user but the very obviously crappy handling of #include_next itself.
Of course the patch fixes something
Thomas Preud'homme wrote:
Ok, I did that one.
http://repo.or.cz/w/tinycc.git/commitdiff/2358b378b3cd526956713f033f5a0ecaa
5f63951
;=)
Wow, that was super fast.
Don't be scared. I found a sketch in an old private branch. ;)
--- grischka
Roy Tam wrote:
2013/1/7 Roy Tam roy...@gmail.com:
2013/1/7 grischka gris...@gmx.de:
-
http://repo.or.cz/w/tinycc.git/commitdiff/943574aba54713ca4a17fe33aadde5abee233b53
Obviously (if you look at the code) this was not a bug but intended
behavior.
Did you tried reverting this commit and try
contrib/whatever/some.h
#endif
or maybe even less.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
the most minimal required change to our existing files?
I suppose it could be three lines such as
#ifdef TCC_CONTRIB_WHATEVER
# include contrib/whatever/some.h
#endif
or maybe even less.
--- grischka
___
Tinycc
,
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Thomas Preud'homme wrote:
Le dimanche 6 janvier 2013 17:03:28, grischka a écrit :
Other candidates for reversion (OTOH):
-
http://repo.or.cz/w/tinycc.git/commitdiff/fc574f14984d11f1ead50560d1bdc5ae
0eaf6d8d The headers from include are copied to win32/include during
install
I'm not sure
Akim Demaille wrote:
This is the kind of things that Autoconf provides bullet proof :(
Maybe it does something but there is no way to know how.
And so we prefer transparency over bullets, nowadays. ;)
--- grischka
___
Tinycc-devel mailing list
Kirill Smelkov wrote:
grischka! Could you please Cc relevant people when talking about
reverting their patches? I was unaware of this issue until recently.
Some of us read lists in batches through gmane...
Okay ...
I'd suggest to move that optimization into its own function
void
but I don't have time to make sure that it
will work.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
this problems on the account
pages, if someone want to see then tell me and I can add a new user to
see then on my account.
Is there a way to let everyone participate? If so I'd suggest to just
post the details here.
Thanks,
--- grischka
___
Tinycc
@@ static int elf_output_file(TCCState *s1, const char
*filename)
Without knowing any details, I just notice that the proposed fix doesn't
match the analysis of the problem: A change within elf_output_file()
has no effect for tcc -run.
--- grischka
to settle down.
Thanks,
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
up now who did something maybe
two years (or even just two months) ago. ;)
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
pstrcpy instead of strcpy.
This is no such case because __bound_memcpy cannot overflow buf[32].
Same with
pstrcpy(buf, sizeof buf, a.out);
Because a.out cannot overflow buf[1024].
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
be '', '|' or '^'),
no-one noticed it.
I guess it was to avoid a compiler warning such as
case X not handled in switch
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Vincent Lefevre wrote:
On 2013-01-31 13:22:22 +0100, grischka wrote:
Vincent Lefevre wrote:
Perhaps there was a default: by default the author forgot to remove.
And as it is probably just useless (if op can only be '', '|' or '^'),
no-one noticed it.
I guess it was to avoid a compiler warning
overflow buf[1024].
sprintf could be used then to save some space
I pushed some changes to that.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
isn't the recommended way to
write a compiler.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
(rather old) ubuntu 64.
http://repo.or.cz/w/tinycc.git/commitdiff/3186455599043938d765b4cc9b92af5fde7241cd
This now compiles for configure --enable-cross without warnings
on both my linuxes 32 and 64 (and passes make test).
Please verify that I didn't break something. Thanks,
--- grischka
by default]
tccrun.c:545:12: warning: ���rt_get_caller_pc��� defined but not used
[-Wunused-function]
make: *** [tccrun.o] Error 1
Thanks. (Maybe) fixed it on mob (untested).
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
-64 is that it has an
lib/x86_64-linux-gnu (empty)
and has
/lib64 (link to /lib)
.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
:(
Fixed on mob. Use tcc -Wl,-subsystem=console/gui ...
Default as before:
- gui for DLL's and for EXE's that have WinMain()
- console otherwise.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo
case the
#ifndef CONFIG_LDDIR
clause in tcc.h now looks right which it didn't before.
Anyhow. Maybe you might want to wait another week with release. ;)
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org
some people cry.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
execstak.
We have to consider to pass an option to ./configure to allow both,
something --with-run
We have --with-selinux, already. Maybe it works for Fedora 18.
-- grischka
M2c
C.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https
Christian Jullien wrote:
Hi all,
At least on Fedora 18, we have to compile with -z execstack which solves the
reported issue.
tcc runs code in memory from malloc. You can try
configure --with-selinux
which uses mmap + some tricks.
--- grischka
(with some gcc versions) that apparently you
don't see. I pass some --extra-cflags.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
the program to itself as if it were in an external
DLL. Non-trivial, also.
--- grischka
Thanks
Henry
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Christian Jullien wrote:
(neither -vv nor -print-search-dirs is shown with -help)
True.
So I did my hopefully last commit for 0.9.26:
http://repo.or.cz/w/tinycc.git/commitdiff/82965594
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel
-tool v`
etc...
That way configure would look better without that inline C code.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
into
their local block, then.
--- grischka
(who wrote:)
Which doesn't make neither cval any more initialized !?!
Maybe just a case of acute GCC warning hysteria.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org
--extra-cflags=-Os -Wall
libc_dir=$(ldd ./print_env_info | grep libc.so | sed
's|[^/]*/\(.*/\)[^/]*|\1|')
ldd doesn't work on my MSYS. I cannot complain because I just have
the downstripped version for git, but maybe you can use
gcc -print-file-name=crt1.o
or such.
Thanks,
--- grischka
= no; then
libc_dir=$(ldd ...
While at it, can't we use the elf-interp from the ldd output, too?
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
.
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
except for the empty
MUA-dir case from the OP (Ramsay).
--- grischka
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
/lib/ld-linux-armhf.so.3
/lib/arm-linux-gnueabihf/ld-linux.so.3))
- $(if $(shell grep -l ^Features.* \(vfp\|iwmmxt\)
/proc/cpuinfo),-DTCC_ARM_VFP)
(Of course I don't insist. Just if you can see a nice solution right now)
Thanks for all your work,
--- grischka
Thomas Preud'homme wrote:
Look at the top of the Makefile. Something's wrong when detecting your
compiler. But the code didn't change, ...
See http://repo.or.cz/w/tinycc.git/commitdiff/108b2876
--- grischka
___
Tinycc-devel mailing list
Tinycc
301 - 400 of 803 matches
Mail list logo
