Re: [Tinycc-devel] Tinycc-devel Digest, Vol 153, Issue 11

I know this is an old post I'm replying to, but this is important. A technique I had learned for an earlier version of TCC no longer works. In particular, using inline ASM to strip the decorations from an exported STDCALL function, no longer works. Previously it worked, and was actually mentioned t

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 233, Issue 3

Maybe this is related to the __attrbiute__((constructor)) issue? Am 03.10.22 um 18:02 schrieb tinycc-devel-requ...@nongnu.org: Date: Sun, 4 Sep 2022 15:42:42 -0400 (AEST) From: Mid Favila Reply-To:tinycc-devel@nongnu.org To:tinycc-devel@nongnu.org Subject: [Tinycc-devel] Potential bug - Xt: Unre

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 224, Issue 5

Nice that it worked, and no problem at all! By the way, some tests might not pass, but I don't remember why, and I've been able to compile even big projects like glib with musl+TCC, so I don't think it's much of a problem. ___ Tinycc-devel mailing list T

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 224, Issue 5

Hello, I just tried it, and it works flawlessly from what i've tested. Thanks a lot! If I run into any more problems, I'll be sure to remove said headers. Jan 17, 2022, 12:01 by tinycc-devel-requ...@nongnu.org: > Send Tinycc-devel mailing list submissions to > tinycc-devel@nongnu.org > > To sub

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 211, Issue 20

> > > > Hi, if you just need definitions from handleapi.h > > > > Drop only the following handleapi.h file in win32/include/winapi and it > should work: > > > > Thank you! This worked! I just commented out the other headers and included windows.h for handleapi.h: /** * This file is part of the

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 211, Issue 19

---cut---cut---cut Tell us if it works. C. From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of D Q Sent: Tuesday, December 22, 2020 21:40 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Tinycc-devel Digest, Vol 211, Issue 19 Thanks. I

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 211, Issue 19

Thanks. I tried copying the headers over. At first, just copying them all from the latest mingw64, but got an error saying tcc does implement VARARGS. Then tried following the chain of dependencies and ran into this: In file included from C:/godot/gdnim/.nimcache/timer_comp/stdlib_io.nim.c:10: In

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 196, Issue 3

Hello All my line has changed according to the answer) rem tcc -vv glfw.def opengl32.def glu32.def -DGLFW_DLL -run triangle.c tcc -vvv -LC:/tcc -lglfw -lopengl32 -lglu32 -DGLFW_DLL -run triangle.c -vvv this option was great) C:\tcc\examples\glfw-2>tcc -vvv -LC:/tcc -lglfw -lopengl32 -lglu32 -D

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 192, Issue 12

Hi, Il 20/05/19 22:08, Ben Hutchinson ha scritto: > But there is ONE POINT TinyCC fails on. This is its insertion of the > __chkstk function. At first I thought since TinyCC was so small that it > was too small to have any code to generate unnececary code. But that is > clearly not the case. It se

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 192, Issue 12

On 5/21/2019 4:08 AM, Ben Hutchinson wrote: Date: Sun, 19 May 2019 01:11:26 +0200 From: Daniel Gl?ckner mailto:daniel...@gmx.net>> If you don't need __chkstk, you are not compiling for Windows and should not use a TinyCC that is targetting Windows. TinyCC targetting Linux

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 192, Issue 12

On Mon, May 20, 2019 at 3:09 PM Ben Hutchinson wrote: > Date: Sun, 19 May 2019 01:11:26 +0200 >> From: Daniel Gl?ckner >> >> If you don't need __chkstk, you are not compiling for Windows and should >> not use a TinyCC that is targetting Windows. TinyCC targetting Linux does >> not emit calls to

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 192, Issue 12

> > Date: Sun, 19 May 2019 01:11:26 +0200 > From: Daniel Gl?ckner > > If you don't need __chkstk, you are not compiling for Windows and should > not use a TinyCC that is targetting Windows. TinyCC targetting Linux does > not emit calls to __chkstk. > > > Not quite true. Assembly language is my sta

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 192, Issue 11

On Sat, May 18, 2019 at 10:45:32AM -0700, Ben Hutchinson wrote: > It requires > MinGW to run in Windows (I'm a Windows user), so that means that using GCC > by itself is simply not an option, because it won't run without its MinGW > dependencies. The whole point of MinGW is that it uses the C libr

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 192, Issue 11

> Date: Fri, 17 May 2019 06:06:18 +0200 > From: Daniel Gl?ckner > > On Thu, May 16, 2019 at 04:09:51PM -0700, Ben Hutchinson wrote: > > The only reason I don't > > use GCC is that overall it is worse at generating bloated code, > > No, try gcc -Os > >textdata bss dec hex filena

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 192, Issue 8

;> I added a "nodecorate" attribute a while ago to handle this (it just >> suppresses the addition of "_" and "@n"). It would be nice to add support >> for reading .def files at some point... >> >> ___ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 192, Issue 8

Ok, I just tried the nodecorate attribute (I'm using TCC version 0.9.27), and it doesn't work. TCC is behaving as if I never typed the nodecorate attribute at all. It's literally completely ignoring that attribute. Here's my code: __attribute((dllexport,stdcall,nodecorate)) int TestFuncStdcall(int

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 168, Issue 1

Hi Zeb here is this not an example of not including the windows static librarys Thankz Sent via my BlackBerry from Vodacom - let your email find you! -Original Message- From: Sender: Tinycc-devel Date: Sat, 1 Apr 2017 12:00:22 To: Reply-To: Subject: Tinycc-devel Digest, Vol 168, Is

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 151, Issue 7

> I think your commit which replaced TOK_memcpy with TOK_memmove broke the > ARM builds, I'm fixed this on mob ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 138, Issue 1

, October 2, 2014 11:45 AM To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Tinycc-devel Digest, Vol 138, Issue 1 Apple should support the usual BSD socket layer since they are BSD compatible. C standards only supports the low level stuff. For a library, look into libuv. Its cross-platform and

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 138, Issue 1

Apple should support the usual BSD socket layer since they are BSD compatible. C standards only supports the low level stuff. For a library, look into libuv. Its cross-platform and handles networking, event loops, and async IO and all that kinda stuff that you would use in a network app. O

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 138, Issue 1

> Date: Wed, 01 Oct 2014 01:27:09 +0200 > From: JFC Morfin > To: tinycc-devel@nongnu.org > Subject: Re: [Tinycc-devel] How to use char "\" > Message-ID: > Content-Type: text/plain; charset="iso-8859-1"; format=flowed > > btw, would you know a clean and clear uptodate C > documentation including

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 136, Issue 6

On Fri, Aug 1, 2014 at 5:10 PM, jiang <30155...@qq.com > wrote: I would like you to explain my patch. I vstore () in bitfield values ​​on the right match, with gen_cast (dt) to achieve. [...] Could you please repost your explanation in english? Thanks,

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 136, Issue 3

> Date: Fri, 1 Aug 2014 15:48:46 +0200 > From: Sia Lang > To: tinycc-devel@nongnu.org > Subject: Re: [Tinycc-devel] tcc grammar problems > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > I fail to see a meaningful discussion and I certainly fail to see many > small commits.

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 134, Issue 16

Hi, On Sun, 22 Jun 2014, jiang wrote: This is my patch (see Annex) tcc result is correct --> 254 / 30 / 126 That's not the correct result. If you think it is the probably because you're confused by the semantics of assignments as rvalue. I guess gcc & mvc repeated use of the register, s

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 134, Issue 18

revert vstore() commitf26fdaefd8b35489f26462992010b9ecd76d8fe3 Thank grischka for letting me know the error hello grischka jiangLet init_putz one-time generation http://repo.or.cz/w/tinycc.git/commitdiff/d316836008f4738d5a020b28aa33e96a82a81aca - may crash the compiler (see gcc w

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 134, Issue 16

This is my patch (see Annex) tcc result is correct --> 254 / 30 / 126 1 1 1 1 1 1 1 0 -> 254 254 & 0x7f (c:7) 1 1 1 1 1 1 1 0 -> 254 0 1 1 1 1 1 1 1 -> 0x7f -&- 0 1 1 1 1 1 1 0 -> 126 (b:5) 0 1 1 1 1 1 1 0 -> 126 0 0 0 1 1 1 1 1 -> 0x1f -&- 0 0 0

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 134, Issue 15

te: On 20/06/2014 06:58, jiang wrote: printf("%d %d %d %d %d\n", + st1.f2, st1.f3, st1.f4, st1.f5); Am i being stupid, or do you specify 5 format specifiers with only 4 arguments?! _______ Tinycc-devel mailing list Tinycc-devel@nongnu.org

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 132, Issue 22

Thanks, this is exactly what I was looking for. It will be nice for the user to be able to deploy a single dll with everything in it for a C scripting inside their .NET applications. Cheers, jhabjan 2014-04-16 18:00 GMT+02:00 : > Send Tinycc-devel mailing list submissions to > tinycc-de

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 131, Issue 4

> Date: Wed, 05 Mar 2014 13:13:43 +0800 > From: z_axis > To: tinycc-devel@nongnu.org > Subject: [Tinycc-devel] please ignore execvl issure ... > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes > > > execvp("xinit", (char *[]){"xinit", "clis

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 129, Issue 5

A second possibility for closed source users of LGPL, is to provide two binaries, one statically linked, one dynamically linked (or dlopen). That might allow the stripping of most symbols from the main.exe but still allowing replacement of the loaded .dll, and additionally allowing access to the f

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 129, Issue 4

Le vendredi 3 janvier 2014, 20:22:29 Graham Swallow a écrit : > You can link an LGPL library into a proprietary binary, PROVIDED, > the end user can relink the same LGPL library into a similar binary. > > You need to provide your binary as a link-kit, to allow this. > With symbols, and a makefile.

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 129, Issue 4

You can link an LGPL library into a proprietary binary, PROVIDED, the end user can relink the same LGPL library into a similar binary. You need to provide your binary as a link-kit, to allow this. With symbols, and a makefile. A pre-built .exe is what the installer uses. They can then relink with

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 126, Issue 10

Dear grischka ! Thank you very much , and thanks a lot to John for the patch ! > grischka wrote: > Btw. there was a related patch here: ... ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.n

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 103, Issue 1

On Wed, 2011-11-02 at 17:29 +0100, Robert Clausecker wrote: > Am Mittwoch, den 02.11.2011, 12:00 -0400 schrieb Ben Bacarisse > > > > It seems that I discovered a bug in tcc. ANSI C allows declaration > > of > > > prototypes containing function pointers like this: > > > > > > void traverse

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 103, Issue 1

Le mercredi 2 novembre 2011 17:29:13, Robert Clausecker a écrit : > Am Mittwoch, den 02.11.2011, 12:00 -0400 schrieb Ben Bacarisse > > > > It seems that I discovered a bug in tcc. ANSI C allows declaration > > > > of > > > > > prototypes containing function pointers like this: > > > void

Re: [Tinycc-devel] Tinycc-devel Digest, Vol 103, Issue 1

Am Mittwoch, den 02.11.2011, 12:00 -0400 schrieb Ben Bacarisse > > It seems that I discovered a bug in tcc. ANSI C allows declaration > of > > prototypes containing function pointers like this: > > > > void traverse(mystruct_t*, void(mycontent_t*)); > > > > tcc currently rejects this giv

Re: [Tinycc-devel] Tinycc-devel

On Thu, Jan 24, 2008 at 08:53:21PM -0200, Manoel Teixeira wrote: > By the way, I?ve compiled an old version using VS2005, generating code to > ARM, running on Windows Mobile, and it's almost 100%. The only problem is > float. The asm emitted is different of that generated by the MS. The one

Re: [Tinycc-devel] Tinycc-devel

_add_library_path(s, "/usr/local/lib"); > tcc_add_library_path(s, "/usr/lib"); > tcc_add_library_path(s, "/lib"); > #endif > > > This way LIBTCC paths also works with DLL? > > TimoVJL > > > > > _____

Re: [Tinycc-devel] Tinycc-devel

From: "Timovj Lahde": > One idea for tcc.c line 133 in function: > > TCCState *tcc_new(void) > > > /* default library paths */ > #ifdef TCC_TARGET_PE > { > tcc_lib_path = w32_tcc_lib_path(); <-- added > char buf[1024]; > snprintf(buf, sizeof(buf), "%s/lib", tcc_l

[Tinycc-devel] Tinycc-devel

One idea for tcc.c line 133 in function: TCCState *tcc_new(void) /* default library paths */ #ifdef TCC_TARGET_PE { tcc_lib_path = w32_tcc_lib_path(); <-- added char buf[1024]; snprintf(buf, sizeof(buf), "%s/lib", tcc_lib_path); tcc_add_library_path(s, buf