including a RiscV one!
On Fri, Jan 1, 2021 at 10:57 PM Christian Jullien wrote:
Here is the result of my study when stddef.h no longer contains [u]intN_t
definitions.
i.e. b) solution
OS | cpu | Compilers | result (including compiling OpenLisp with
installed tcc
] Error 1
memtest
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Christian Jullien
Sent: Monday, January 04, 2021 07:18
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] x86_64 tcc doesn't set sign bit
Hi Michael,
The fix does not make the test suite happy, at least, on Linux Aarch64 when
clang is used (gcc and tcc are Ok):
./configure --strip-binaries --with-selinux --cc=clang
--prefix=/home/jullien/tinycc/static
Binary directory/home/jullien/tinycc/static/bin
TinyCC directory
)
On 1/3/21 4:07 PM, Christian Jullien wrote:
> Hello,
>
> I confirm it is fixed except, probably not related to you commits, on
> Aarch64 Linux using clang, I get:
>
> ./configure --strip-binaries --with-selinux --cc=clang
> --prefix=/home/jullien/tinycc/static
> -
gmake[2]: *** [Makefile:166: dlltest] Error 1
Perhaps Herman has an idea on how to fix it?
C.
-Original Message-
From: Danny Milosavljevic [mailto:dan...@scratchpost.org]
Sent: Sunday, January 03, 2021 15:54
To: Christian Jullien
Cc: jull...@eligis.com; tinycc-devel@nongnu.org
Subject
Hi,
Danny huge commit for arm code breaks aarch64 (as with Fedora 33 on RPi):
On this 64bit system, it tries to compile arm-asm:
...
gcc -o arm64-link.o -c arm64-link.c -DCONFIG_LDDIR="\"lib64\"" -DHAVE_SELINUX
-D
TCC_TARGET_ARM64
.
Christian.
-Original Message-
From: Christian Jullien [mailto:eli...@orange.fr]
Sent: Saturday, January 02, 2021 06:36
To: 'tinycc-devel@nongnu.org'
Subject: RE: [Tinycc-devel] issues/questions with stddef.h which comes with tcc
Thank you for your long reply which confirms what I
Hello,
On Fri, 1 Jan 2021, Christian Jullien wrote:
> First, happy new year all.
To you as well.
> Porting tcc on *BSD systems raised issues/questions with stddef.h from tcc
> distrib.
>
> First, it contains a mix of definitions coming from both stddef.h and
> stdint.h I
confident of them
to be sure that every GCC include tree will work. Does Clang work? Is it a
license issue? If so, that's passing the license issue on to you.
On Fri, Jan 1, 2021 at 7:45 AM Christian Jullien wrote:
First, happy new year all.
Porting tcc on *BSD systems raised issues
First, happy new year all.
Porting tcc on *BSD systems raised issues/questions with stddef.h from tcc
distrib.
First, it contains a mix of definitions coming from both stddef.h and
stdint.h IMHO it should only contain what stddef.h is supposed to contain.
i.e. From C11:
B.18 Common
Hi team,
We have an official 0.9.27 version which is now quite old. Very often we get
reported BUGs which have been fixed long ago on mod.
This year, tcc also received a lot of new ports: Linux/riscv64, macOs, many
*BSD.
I think it's really time to increase tcc version. Maintainers, could
8:00 +0100
From: "Christian Jullien"
To:
Subject: Re: [Tinycc-devel] handleapi.h not found
Message-ID: <000f01d6d824$9ce369a0$d6aa3ce0$@orange.fr>
Content-Type: text/plain; charset="utf-8"
Hi,
Indeed, many includes are missing until you can include handleapi.h
You
Hi Grischka,
Clang reports the following warnings with your new c2str.c source file
(found with RPi4 arm and other platforms using clang):
clang -o c2str.exe tests/misc/c2str.c && ./c2str.exe include/tccdefs.h
tccdefs_.h
tests/misc/c2str.c:58:19: warning: passing 'unsigned char *' to
Hi,
Indeed, many includes are missing until you can include handleapi.h
You can find them all in recent version of Mingw64, for example in
mingw64-10.2.0-crt-8.0.0-with-ada.7z
You can submit a tar.gz with all missing files to this list and let maintainer
add them in
tcc Linux/riscv-64 is now part of my OpenLisp compiler non-regression plateform
and the result is as good as if compiled with gcc (except of course execution
speed).
My huge OpenLisp test suite runs flawlessly when using tcc.
For my use, this port is fully functional. I use a Gnufarm emulated
Brugge via Tinycc-devel
Sent: Saturday, December 19, 2020 07:25
To: tinycc-devel@nongnu.org
Cc: Herman ten Brugge
Subject: Re: [Tinycc-devel] Grischka last commit breaks some ports
On 12/18/20 2:45 PM, grischka wrote:
> Christian Jullien wrote:
>> On OpenBSD:
>
> I noticed some test
On OpenBSD:
Test: 106_pthread...
106_pthread.c:13: warning: implicit declaration of function
'pthread_condattr_setpshared'
tcc: error: undefined symbol 'pthread_condattr_setpshared'
diff: 106_pthread.output: No such file or directory
gmake[3]: *** [Makefile:122: 106_pthread.test] Error 2
I just recompiled you test program with mob. On Windows, cl, clang, gcc and ...
tcc all produce the same output result.
Sorry, I can't reproduce.
C.
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Vincent Lefevre
Sent:
Hi I do not confirm.
Making mod by bootstrapping tcc (32+64) using Cygwin, then using tcc to compile
itself does not produce error even with the test suite.
What exact command did you used to compile tcc?
C.
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Hi team,
I'm probably not too far to have a working tcc on OpenBSD.
- I've got a tcc which produces a .o: tcc -c foo.c
- The link sequence is /usr/lib/crtbegin.o foo.o /usr/lib/crtend.o
and tcc has already been modified to produce this sequence on OpenBSD
instead or
Yes, “20 year old OS” has also been my first reaction.
However, I have a deep respect for people doing retro computing. I personality
maintain machines even older. One of them is a PII 333Mhz machine which still
works well on Debian 10.6 … and tcc.
I don’t see any reasons to not help people
:prolo...@shortcircuit.net.au> prolo...@shortcircuit.net.au
W: <mailto:https://prologic.shortcircuit.net.au> prologic.shortcircuit.net.au
Blog: <https://prologic.blog/> Read my Blog
Twtxt: <https://twtxt.net/user/prologic> Follow me on twtxt.net
On Sun, Nov 29
Hello,
Structures "generally" have around 10 to 20 variables.
There is also cases where there are huge when they collect all "global"
variables of a lib.
This append for example if you need multiple instance of the same lib, each
having its own state.
Doing so has the advantage to put variables
ead my Blog
Twtxt: <https://twtxt.net/user/prologic> Follow me on twtxt.net
On Sun, Nov 22, 2020 at 3:43 AM Christian Jullien wrote:
James,
Have you tried "CC=tcc ./configure --enable-shared=no" as I said.
It works ROOTB with sudo-1.9.3p1.tar.gz on both arm (RPi) and x64
re they with / without the fix ? Because normally the changes would
> address those I saw them too.
>
> On Thu, 26 Nov 2020 at 16:14, Christian Jullien wrote:
> >
> > Same result, also NetBSD still fails with:
> >
> > -bash-5.0$ ./configure
> > Binary direc
Same result, also NetBSD still fails with:
-bash-5.0$ ./configure
Binary directory/usr/local/bin
TinyCC directory/usr/local/lib/tcc
Library directory /usr/local/lib
Include directory /usr/local/include
Manual directory/usr/local/share/man
Info directory /usr/local/share/info
I've just tried on the latest FreeBSD x64 and, not related to your patch, it
fails as before on:
gmake[1]: Entering directory '/usr/home/jullien/tinycc/lib'
../tcc -c libtcc1.c -o libtcc1.o -B.. -I..
../tcc -c alloca86_64.S -o alloca86_64.o -B.. -I..
../tcc -c alloca86_64-bt.S -o alloca86_64-bt.o
fix ?
On Thu, 26 Nov 2020 at 13:38, Christian Jullien wrote:
>
> It's really cool then, have you recently tried other BSD flavors: FreeBSD,
> OpenBSD and NetBSD?
> I made few attempts in the past.
>
> -Original Message-
> From: Tinycc-devel [mailto:tinycc-devel-
:18
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] [PATCH] DragonFlyBSD build fix proposal
It works I was able to compile few programs with, tests fail in same
way as on Linux (current mob branch).
On Thu, 26 Nov 2020 at 12:59, Christian Jullien wrote:
>
>
Thanks but are sure it really works passing all the tests?
Few years ago I tried different BSD versions and, for one reason or another,
they all failed.
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of David CARLIER
Sent:
Hi,
Testing mob on different systems, I get the following new errors on:
Arm (RPi):
arm-gen.c: In function 'gen_cvt_itof':
arm-gen.c:2140:7: warning: implicit declaration of function 'vpushsym'; did
you mean 'vpushv'? [-Wimplicit-function-declaration]
vpushsym(func_type,
James,
Have you tried "CC=tcc ./configure --enable-shared=no" as I said.
It works ROOTB with sudo-1.9.3p1.tar.gz on both arm (RPi) and x64
w.o. --enable-shared=no it fails because tcc does not support or recognize
-Wl,--version-script, maybe tcc should simply ignore this option.
-Original
Tcc does not support all the ld options used by gcc, especially when building
.so.
.a are much better supported.
Even on RPi, I can compile the latest sudo version using only static libs:
tar xvzf sudo-1.9.3p1.tar.gz
cd sudo-1.9.3p1/
CC=tcc ./configure --enable-shared=no
make
# First
With a friend of mine, we tried a POC with z80 this year to see how it goes.
While feasible, there is a great amount of work. For our POC, instead of
generating .o which changes from target platform, we generated .asm and use the
platform assembler, linker …
We also choose to generate only
on my current x86_64 machine with latest
fedora.
Herman
On 11/10/20 7:21 AM, Christian Jullien wrote:
Hi Herman,
I quickly replaced __APPLE__ by __clang__ in 114 test but, as this test is
not reproducible, I can't say it is the right fix to apply.
I ran changes locally on Debian x86_64 and RPi
: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Christian Jullien
Sent: Monday, November 09, 2020 21:24
To: jull...@eligis.com; tinycc-devel@nongnu.org
Cc: 'Herman ten Brugge'
Subject: [Tinycc-devel] Seg fault with test 114 on Debian x64
Hi again Herman,
I
Hi again Herman,
I continue to test mod with your latest patch on the (many) machines I have.
This time, it is a Debian 10.6 x86_64 fully up to date and, guess what?, it
fails on test 114 with clang 7.0, (gcc worked).
See log below:
jullien@debian64:~$ uname -a
Linux debian64
: [Tinycc-devel] Seg fault with test 114 on Debian i686
The problem is in libc. I pushed a patch for older libc's.
The real problem is in the signal handling in the pthread_create
implementation.
There are changes in glibc-2.32 to fix this.
Herman
On 11/8/20 11:10 AM, Christian Jullien wrote
Update,
It curiously don't seg fault on an even older laptop also install with
Debian 10.6. Laptop is a PIII 333MHz 256MB ram
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Christian Jullien
Sent: Saturday, November 07, 2020 15:52
To: tinycc-devel
Hi all,
I don't used i686 these days but, from time to time, I boot a very old
laptop running Debian (currently 10.6) on a i686.
Today, I gave a try with tinycc mod and got an reproducible error with test
114. Here is what I get:
jullien@simtest:~/tinycc$ uname -a
Linux simtest
Thank you, I confirm it is fixed on macOS and it still works on Windows x86 &
x64.
C.
-Original Message-
From: Michael Matz [mailto:matz@frakked.de]
Sent: Thursday, October 01, 2020 18:05
To: Christian JULLIEN; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] attribute a
Hi, testing your changes on macOS gives:
Test: 120_alias...tcc: error: undefined symbol '_alias_for_target'tcc: error:
undefined symbol 'target'--- 120_alias.expect 2020-10-01 16:27:18.0
+0200+++ 120_alias.output 1970-01-01 01:00:00.0 +0100
Le :30 septembre 2020 à 18:07
Hi Michael,
I see no issue on Windows (tested with x86, x86_64), on RPi arm or RPi aarch64.
Good job.
Christian
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Michael Matz
Sent: Wednesday, September 30, 2020 18:05
To:
Hi,
To help you, few questions:
- Are you using the latest version from mod? If not, I invite you to
get mod and try again
- If it still fails, can you give us the exact system you’re using,
the C compiler and compiler version you use for bootstrap, and the CPU you run
Subject: Re: [Tinycc-devel] Debian x64 bootstrap error with clang
Can you test attached patch.
There might be more places that use __APPLE__ that should be done
differently.
You can commit if it works because I cannot test it.
Herman
On 2020-09-19 06:48, Christian Jullien wrote:
Hi I
Hi I generally test tcc Linux x64 on Fedora 32, giving a try on an up to
date Debian v10.5, while it works with gcc, using clang, I get:
jullien@debian64:~/tinycc$ uname -a
Linux debian64 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64
GNU/Linux
jullien@debian64:~/tinycc$
The few last commits leave mob in bad state!!
The last state on which I trust is after my revert “Revert commit
55f8963dfab5c543f7f34589d3ef9d3f2da3db14 from wanjochan until better tested on
all platforms”
After this one:
Minor issue: Kyryl “add tests for float conversions to u64” added
ubject: Re: [Tinycc-devel] Error with today's patches
Hey Christian Jullien, the patch is only a temporary workaround to get
correct code gen working. Right I have to confront the C standard
to understand if calling __fixunsxfdi on long double to uin64_t
is actually correct. And if we need to fi
Hi Kyryl,
First I personally appreciate you want to make tcc even better.
Unfortunately your fixes are unclear about what they fix.
It's hard to see if they don't introduce a regression on another platform.
For example, long double has not the same precision on x64 or on Aarch64. It
easy to
that Christian, while working on his own language, is
right in many ways You should read him with attention.
Take care all, and sorry for this.
ian
Le 09/09/2020 à 11:44, Christian Jullien a écrit :
macOS:
compiling tcc.c 10 times
(827 ms)
test3
tcc
macOS:
.
compiling tcc.c 10 times
(827 ms)
test3
tcc: error: undefined symbol '___va_arg'
tcc: error: undefined symbol '_alloca'
make[2]: *** [test3] Error 255
memtest
RPi:
running fib in threads
1 8 144 5 10946 21 6765 89 55
Thanks, it seems to be backend dependent.
More feedbacks:
On RPi 32bits (arm), tested with tcc, gcc and clang:
jullien@sims4:~ $ tcc foo.c && ./a.out
50
132
a.out: foo.c:11: main: Assertion `x.bits24==0' failed.
Aborted
jullien@sims4:~ $ gcc foo.c && ./a.out
0
0
jullien@sims4:~ $ clang foo.c &&
Hi,
You have in mob (win32/include/winapi) all the include files to write simple
http applications.
I daily use them to implement many network protocols (both client and server).
Among them you have: winsock2, h ws2ipdef.h and ws2tcpip.h
You must link with ./win32lib/ws2_32.def
C.
>
> If yes, sorry for the noise.
Ah indeed, no I wasn't apparently, thanks!
> On 2020-08-18 18:45 +0200, Christian JULLIEN wrote:
> > Recent change has an issue with some tests
> >
> > macOS x64 and Linux ARM test3 tcctest.c:1939:
> > err
Recent change has an issue with some tests
macOS x64 and Linux ARM test3 tcctest.c:1939: error:
duplicate case valuemake[2]: *** [test3] Error 1 memtest
../tests/tcctest.c:1939: error: duplicate case valuemake[2]: ***
[memtest] Error 1
Linux
Hi,
wanjochan recently added scripts to build win32.
There are currently many different ways to build tcc on windows with standard
tools and scripts.They may not totally fit you need and probably lack
documentation but they do exist and I don't think we need more (confusing)
scripts.
For
Objet :Re: [Tinycc-devel] arm shared build issue
It works on my raspberry pi.
Did you also compile tcc with the new mob branch?
Herman
On 2020-08-05 15:02, Christian JULLIEN wrote:
Thanks but are you sure it is fixed
sion0ofVerneedrecord
jullien@sims4:~/tinycc$
Le :05 août 2020 à 14:02 (GMT +02:00)
De :"Herman ten Brugge via Tinycc-devel" tinycc-devel@nongnu.org
À :"tinycc-devel@nongnu.org" tinycc-devel@nongnu.org
Cc :"Herman ten Brugge" hermantenbru...@home.nl
Objet :Re: [Tiny
Herman, thanks for recent DLL (shared) support on more platforms.
Tryingtoplaywithrecentarmsharedsupport,Icompiledtccwiththisbashfunction
onRPiarm:
shared_build(){
echo===Boostrappingwith$1shared
./configure--cc=$1--disable-static--prefix=$(pwd)/dist
make#make-ktest
sudomakeinstall-strip
est fail
(reported by Christian Jullien).
Thanks for the report, it was indeed unhandled in the support routines. I
fixed this in mob for riscv64, but the routines are shared with aarch64 so
it's likely also fixed there, please check.
Thanks. Everything is fine now.
--
Vincent Lefèvre vinc...@vinc
Hi,
Trying to compile mpfr using tcc (with Vincent Lefèvre help) we've found that
Rpi aarch64, gcc gives:
/home/jullien/tinycc$ gcc -dM -E -xc /dev/null | grep LDBL#define
__LDBL_MANT_DIG__ 113#define __LDBL_MAX__
1.18973149535723176508575932662800702e+4932L#define __LDBL_MAX_EXP__
Hi,
dlfcn provides declarations for functions dlopen/dlsym/dlclose that allow to
dynamically load a shared lib at runtime on unix systems.Windows uses a similar
but different interface to load DLL (which are different from .so shared
libs).Hence, you don't need dlfcn.h on Windows.
Systems like
e other hand, if it's only aliases to existing options, possibly which are
enabled only on OSX, then I don't think [m]any would object, and it should
be fairly simple to add and possibly revert later.
On Saturday, July 11, 2020, 08:09:07 AM GMT+3, Christian Jullien
<mailto:eli...@orange.fr>
t now. Wouldn't it be better to specify the
absolute
install [libdir] ?
Avi
On Thursday, July 9, 2020, 08:40:42 PM GMT+3, Christian Jullien
<mailto:eli...@orange.fr> wrote:
I’ve found another (and better) way to achieve this:
-Wl,-rpath,"@executable_path/$(TOP)
<mailto:
Hi maintainers,
As often, Apple reinvent the wheel and makes things differently.
Among other, clang handles shared libs .dylib with a different set of
compiler options.
For example, -shared is replaced by -dynamiclib etc.
It means that a ./configure must test if it uses clang or tcc and
Thank you for testing the different configure options on macos.
I can easily fix this but it will fail later. I'm not sure that tcc is
currently able to generate .dylib
tcc -shared -o libtcc.dylib libtcc.o tccpp.o tccgen.o tccelf.o tccasm.o
tccrun.o x86_64-gen.o x86_64-link.o i386-asm.o
, 2020 23:58
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Tiny c availability
Christian Jullien wrote in
<003901d65604$ce397be0$6aac73a0$@orange.fr>:
|I added USES file which list known projects working with tcc. To be \
|completed
With zest.
--steffen
devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Christian Jullien
Sent: Thursday, July 09, 2020 19:07
To: tinycc-devel@nongnu.org; jull...@eligis.com
Cc: 'avih'
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after
cleanup
Thanks avih, another step
6
When not using --disable-static, then tcc runs fine, compiles and even -run
works.
On Thursday, July 9, 2020, 07:07:12 PM GMT+3, Christian Jullien
wrote:
?? can you please try with mob and give me the complete log?
The fix is “macos: tcc searches for libtcc.dyln in the same d
.
On Thursday, July 9, 2020, 06:38:10 PM GMT+3, Michael Matz
wrote:
Hello Christian,
(I missed the question earlier, apologies)
On Thu, 9 Jul 2020, Christian Jullien wrote:
> If you have a moment, can you please test if my macos fix for dyld also
> works on your configuration
: DYLD_LIBRARY_PATH no longer works after
cleanup
Hello Christian,
(I missed the question earlier, apologies)
On Thu, 9 Jul 2020, Christian Jullien wrote:
> If you have a moment, can you please test if my macos fix for dyld also
> works on your configuration?
Yes, it works fine here on my emulated
I added USES file which list known projects working with tcc. To be
completed
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Steffen Nurpmeso
Sent: Thursday, July 09, 2020 15:47
To: tinycc-devel@nongnu.org
Subject: Re:
,
On Wed, 8 Jul 2020, Christian Jullien wrote:
>
> It is still unclear why it does not work but on macOS, ./configure
> –disable-static Now raises an error:
>
> hello-exe
>
> === recurse /Users/jullien/tinycc/tests/.. ===
>
> dyld: Libra
+0200, Christian Jullien wrote:
> We are many to use it daily as main C compiler for really big projects.
It think that's a bit exaggerated. From what I saw on this list you
can count the number of people who use it for "really big projects" on
one hand. A few people turned to tcc b
atz
Sent: Wednesday, July 08, 2020 17:35
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after
cleanup
Hello,
On Wed, 8 Jul 2020, Christian Jullien wrote:
>
> It is still unclear why it does not work but on macOS, ./configur
For sure it is.
We are many to use it daily as main C compiler for really big projects.
See recent commits here: https://repo.or.cz/w/tinycc.git
It does not release official versions too often but mod is definitely the
version you should take. For example, macOS received recently a native tcc
rom: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Michael Matz
Sent: Wednesday, July 08, 2020 17:35
To: jull...@eligis.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after
cleanup
Hello,
On We
The code cleanup now sets DYLD_LIBRARY_PATH this way in Makefile:
NATIVE_TARGET = $(ARCH)
ifdef CONFIG_OSX
NATIVE_TARGET = $(ARCH)-osx
ifneq ($(CC_NAME),tcc)
LDFLAGS += -flat_namespace -undefined warning
endif
export MACOSX_DEPLOYMENT_TARGET := 10.6
export DYLD_LIBRARY_PATH
Hi, it now fails at least on RPi:
=== Boostrapping with gcc
Binary directory/usr/local/bin
TinyCC directory/usr/local/lib/tcc
Library directory /usr/local/lib
Include directory /usr/local/include
Manual directory/usr/local/share/man
Info directory /usr/local/share/info
Doc
is=orange...@nongnu.org] On
Behalf Of Christian Jullien
Sent: Sunday, July 05, 2020 20:55
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] How to programming winsock on tcc
You may need to grab more include files from
https://download.savannah.gnu.org/releases/tinycc/winapi-full-for-0.9.27.
You may need to grab more include files from
https://download.savannah.gnu.org/releases/tinycc/winapi-full-for-0.9.27.zip
C.
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of blue sky
Sent: Sunday, July 05, 2020 18:29
To: tinycc-devel@nongnu.org
Hi Ongta, as with VC++, il have to include ws2_32 lib which, for tcc on Windows
is passed as –lws2_32 on command line.
So command line looks like:
tcc –o foo.exe foo.c –lws2_32
Hope it helps.
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of
evel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Christian Jullien
Sent: Sunday, July 05, 2020 06:56
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] POSIX compliance; spaces not supported with -l for
libs
Hello John,
I like very much the idea to make tcc POSIX compliant. I still wo
Hello John,
I like very much the idea to make tcc POSIX compliant. I still work on C/C++
normalization in AFNOR group and worked on different groups including ISLISP
and POSIX, so standards matter for me :).
Please, also consider that neither gcc nor clang support space after -O:
$ clang -O 3
@byas /tmp % ./foo
foo: 1
jullien@byas /tmp %
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Christian Jullien
Sent: Wednesday, June 24, 2020 16:37
To: arn...@skeeve.com; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] M
rt. clang and
tcc .o are not compatible
"Christian Jullien" wrote:
> I think that what annoys me the most is that standard ar and ranlib
commands do not work with tcc generated .o files.
> For sure, I can drop ranlib calls and replace ar by "tcc -ar rcs" but this
must be done i
ably won't be able to use any open source package with
"CC=tcc ./configure".
C.
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On
Behalf Of Christian Jullien
Sent: Tuesday, June 23, 2020 20:42
To: 'Michael Matz'
Cc: tinycc-devel@no
20:06
To: jull...@eligis.com
Cc: tinycc-devel@nongnu.org
Subject: RE: [Tinycc-devel] Major issue with current macos port. clang and
tcc .o are not compatible
Hello,
On Tue, 23 Jun 2020, Christian Jullien wrote:
> I agree that it is the same on Windows however on macOS and more
> generally on
, Christian Jullien wrote:
> As suspected, I have a proof that current version does not allow to mix
> clang and tcc objects (which is of course a big issue).
Well, of course, that's exactly the same as if someone tried to do similar
things on Windows, the .o files from there and tcc
Hi All,
As suspected, I have a proof that current version does not allow to mix
clang and tcc objects (which is of course a big issue).
The root of this issue is that a tcc .o is not a Mach-O but a ELF 64 object
file.
After successfully compiled tcc here is my test:
--- foo.c
Int foo =
Hi, as macOS uses clang, I also tried to compile tcc with clang on RPi but a
test fails as below
jullien@sims4:~/tinycc-ba8980f $ ./configure --cc=clang; make && make test
.
tcc in threads
1 2 5 3 21 8 34 89 233 1597 2584 13 987 55 144 377 6765 10946 4181 610
(2416 ms)
compiling tcc
Trying tcc with OpenLisp, I get:
Making amalgamation from temporary amalgamation.c
amalgamation.c:14157: warning: implicit declaration of function '__builtin_nanf'
amalgamation.c:44658: warning: implicit declaration of function
'__builtin_huge_val'
amalgamation.c:73738: warning: implicit
gis=orange...@nongnu.org] On
Behalf Of Christian Jullien
Sent: Sunday, June 21, 2020 06:56
To: tinycc-devel@nongnu.org; jull...@eligis.com
Cc: 'Karl Yerkes'
Subject: Re: [Tinycc-devel] Mach-O (i.e. MacOS) support
Hello Matz,
Amazing!! I'm glad to be the first to tell you it works ROOTB including all
tests
[]
4 warnings generated.
OK
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of Michael Matz
Sent: Saturday, June 20, 2020 23:47
To: jull...@eligis.com; tinycc-devel@nongnu.org
Cc: Karl Yerkes
Subject: [Ti
Hi, it looks new and I've not tested this solution but it may help to
finally get a native tcc port on macOS. Image is around 200Gb
https://github.com/sickcodes/Docker-OSX
C.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
May 2020, Christian Jullien wrote:
> I confirm! I tested this sample with mod on Debian RPi 4 armv7l and had a
> similar error:
>
> $ tcc -static foo.c
> tcc: error: Unknown relocation type for got: 107
This, as well as Scotts problem, are relocations for thread local storage.
Sev
Hi Scott,
I confirm! I tested this sample with mod on Debian RPi 4 armv7l and had a
similar error:
$ tcc -static foo.c
tcc: error: Unknown relocation type for got: 107
$ tcc foo.c
-hh help says:
-static link to static libraries (not recommended)
Why is it not
://repo.or.cz/tinycc.git
scp -P 1 -r tinycc root@localhost:.
Run configure/make/make test as usual.
Regards,
Herman
On 2020-05-26 07:43, Christian Jullien wrote:
For Michael,
Again, many thanks for riscv64 backend.
I finally found a way to give riscv64 a try . and it is again from
-devel] riscv64 feedback
Hello,
On Tue, 26 May 2020, Christian Jullien wrote:
> Tcc is configured with: ./configure --with-selinux
Does it work without selinux? I've not tried that for riscv, my qemu
userspace (debian) isn't selinux enabled, and as the symptom you see is
related to mapp
vel] riscv64 feedback
On 5/26/20 7:43 AM, Christian Jullien wrote:
For Michael,
Again, many thanks for riscv64 backend.
I finally found a way to give riscv64 a try . and it is again from Fabrice
Bellard solution using jslinux online VM.
For that I use the fedora29 risvc64 vm in text mod
201 - 300 of 824 matches
Mail list logo
