Oh, I missed that, sorry.
conftest returns "arm-linux-gnueabihf" as expected, but the test in the
next line (configure:323):
if test -n "$tt" -a -f "/usr/lib/$tt/crti.o" ; then
is not true, because I do not have a directory such
/usr/lib/arm-linux-gnueabihf
[OFF]
It is funny though,
As said, it's a temporary tool deleted by ./configure right after it's use.
rm -f $TMPN* $CONFTEST
Can you trace configure script to see how it uses $CONFTEST in different places
and why configure.mak is not correct?
C.
-Original Message-
From: Tinycc-devel
Triplet is given by the temporary conftest tool. You can make it with:
$ gcc conftest.c -o conftest && ./conftest triplet
arm-linux-gnueabihf
Try to debug this very small C program to see why triplet is not defined on
your system.
-Original Message-
From: Tinycc-devel
What is in your triplet? Mine is empty.
On 12/23/18 2:22 PM, Christian Jullien wrote:
On Raspbian, running ./configure I get:
jullien@sims3:~/tinycc $ more config.mak
# Automatically generated by configure - do not modify
prefix=/usr/local
bindir=$(DESTDIR)/usr/local/bin
On Raspbian, running ./configure I get:
jullien@sims3:~/tinycc $ more config.mak
# Automatically generated by configure - do not modify
prefix=/usr/local
bindir=$(DESTDIR)/usr/local/bin
tccdir=$(DESTDIR)/usr/local/lib/tcc
libdir=$(DESTDIR)/usr/local/lib
includedir=$(DESTDIR)/usr/local/include
I figured out. ARM_EXIDX was skipped because TCC_ARM_EABI was not
defined. What I did was just run ./configure without any arguments and
then a "make". Maybe this provides a clue to the maintainers.
After hacking the defines (-DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT), tcc now
does not crash during
In tccelf.c:2359, it clearly jumps to the end of the loop.
And dies in the next loop: /* second short pass to update... */
Take this gdb fragment as an explanation:
Breakpoint 3, tcc_load_object_file (s1=0x45a098, s1@entry=0x454150,
fd=4562744, fd@entry=3, file_offset=4563600,
On Sun, Dec 23, 2018 at 11:44:50AM +0100, Barath Aron wrote:
> I traced the whole object loading procedure with gdb:
> - ARM_EXIDX (section 6) is definitely not loaded, I traced it with gdb.
Where did tcc decide to skip ARM_EXIDX?
___
Tinycc-devel
After looking into the code, my guess is that it's garbage.
I traced the whole object loading procedure with gdb:
- ARM_EXIDX (section 6) is definitely not loaded, I traced it with gdb.
- However, section 7 is loaded, despite of it refers to an unloaded
section (in my case: section 6).
Aron
Aron, I really would love to help you but I know nothing about ELF.
From your mail, I'm only able to tall that s (0x4) from:
$2 = {s = 0x4, offset = 0, new_section = 45 '-', link_once = 0 '\000'}
Is not a valid address to allow to take sh_num. Don't ask me why.
sm_table[sh->sh_info].s->sh_num;
Scroll back to my mail dated on 12/3/18, 5:34 PM for details of the crash.
On 12/23/18 10:07 AM, Christian Jullien wrote:
Ouch! I don’t know about ARCH ARM Linux, I can just say it works nicely on RPi
ARM board:
jullien@sims3:~ $ tcc -v
tcc version 0.9.27 (ARM Hard Float Linux)
Ouch! I don’t know about ARCH ARM Linux, I can just say it works nicely on RPi
ARM board:
jullien@sims3:~ $ tcc -v
tcc version 0.9.27 (ARM Hard Float Linux)
jullien@sims3:~ $ uname -a
Linux sims3 4.14.89-v7+ #1182 SMP Tue Dec 18 00:35:25 GMT 2018 armv7l GNU/Linux
jullien@sims3:~ $ cat hello1.c
Let we argue about the "almost bug free" thing. I have a major issue
with 0.9.27:
$ tcc -v
tcc version 0.9.27 (ARM Linux)
$ uname -a
Linux alarm 4.18.13-1-ARCH #1 SMP PREEMPT Thu Oct 11 02:22:56 UTC 2018
armv7l GNU/Linux
$ cat hello1.c
#include
int main(int argc, char* argv[])
{
I’m not the maintainer of tcc but I’ve no sign of a new version anytime soon.
What I can say however is that:
- 0.9.27 released last year is damn good and almost bug free on
supported platforms (I personally tested)
- Since last release, tcc activity has been rather low and I
14 matches
Mail list logo
