Re: [Tinycc-devel] Add support of musl-libc to tinycc
On Saturday, May 13, 2017 10:01 AM, grischka wrote: >> 3. It seems that (with musl) tcc needs stdarg.h included before stdio.h, or >> else > You could create a stdio.h in /include ... While I could do that (and thanks, wasn't aware of #include_next), va_list et-al are required by more than one std include file. The headers which need it could also change over time. My hope was to find a reasonably inter-operable way to communicate it between the libc and tcc. Rich Felker noted that musl expects __builtin_va* intrinsic or predefined macros, which to me doesn't sound unreasonable. While the subject seems to have drawn some responses with workarounds (your reply included), I haven't yet seen a response which states that it's a bad idea for tcc to follow. Is it a bad idea for tcc to follow? >> 4. Initializers of NAN fail with "division by 0 in a constant", but I was >> _not_ > tcc knows __nan__ Yup, I was aware of it and I forgot to mention that it works. However, as I noted in my followup email about the NAN subject, the main question here, IMHO, is whether or not 0.0f/0.0f should be allowed in static-storage initializer. If it's allowed, then it's probably best to fix it in tcc. But if not, then musl does something which breaks tcc, and it needs to be communicated somehow between tcc and musl. Or work around it in tcc, for instance by replacing NAN with __nan__ before musl's headers get a chance to do a bad substitution. > > 5. tcc dislikes some #defines ... > According to the standard "#define ... defined" is undefined. > Undefined identifiers however evaluate to 0: ... Right. So this one is mpv's fault. Good solution :) >> All that being said, after replacing the NANs with 0, moving include stdarg >> to >> the top, and modifying the #define, mpv builds with tcc cleanly and runs fine >> on alpine (with video, opengl, audio, etc). > Doesn't sound too bad ;) > --- grischka And I even forgot to mention the best part: tcc did it more than 20x faster! More build info: - I used unofficial configure + Makefile because the official build system (waf) doesn't know tcc and I couldn't fix it easily. - Using 15W mobile Haswell CPU. - configure completed in 1.1s with tcc, 3.5s with gcc - make -j4 for ~150 C files completed in 1(!).0s with tcc, 26s with gcc. So yeah, not bad at all indeed :)___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
avih wrote: I tested tcc on alpine linux (has gcc and musl-libc only) and noticed: 1. tcc commit 1094891 broke musl detection on alpine. I disabled auto-detection and added a switch instead ./configure --config-musl and a suggestion to use it if musl is detected "Perhaps you want ./configure --config-musl" 2. While all the tests now pass, if tcc is used to build tcc again, tests fail. Could be setjmp/longjmp or jmp_buf size/alignment. 3. It seems that (with musl) tcc needs stdarg.h included before stdio.h, or else You could create a stdio.h in /include #include "stdarg.h" #include_next 4. Initializers of NAN fail with "division by 0 in a constant", but I was _not_ tcc knows __nan__ 5. tcc dislikes some #defines (I couldn't reproduce in a minimal case), e.g.: A: #define HAVE_CHMAP_API \ (defined(SND_CHMAP_API_VERSION) && SND_CHMAP_API_VERSION >= (1 << 16)) According to the standard "#define ... defined" is undefined. Undefined identifiers however evaluate to 0: #define HAVE_CHMAP_API (SND_CHMAP_API_VERSION >= (1 << 16)) All that being said, after replacing the NANs with 0, moving include stdarg to the top, and modifying the #define, mpv builds with tcc cleanly and runs fine on alpine (with video, opengl, audio, etc). Doesn't sound too bad ;) --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
On 12.05.2017 22:22, u-j...@aetey.se wrote: > On Fri, May 12, 2017 at 08:17:34PM +0200, Kamil Rytarowski wrote: NetBSD libc has hard requirement on __builtin_va_list (or some equivalent builtin). Without it, we cannot use TCC on NetBSD. >>> >>> Would you elaborate in which way the requirement is "hard"? >> >> We require C and C++ compilers that ship with popular extensions on par >> with GCC. >> >> Old va_list has been retired with the following commit: >> >> https://github.com/NetBSD/src/commit/9735e84a7821b8a9cc42139d798ee188c4dd9368 >> >> This restricts NetBSD to GCC, Clang, PCC and perhaps ICC. > >> We set minimum reasonable set of features mandatory in the toolchain. > > I would say you make it harder to build with other toolchains but > unsupported is still not impossible. > > OTOH there is probably little motivation to insist on a "native" tcc > toolchain on NetBSD, because Linux binaries buildable under NetBSD with > tcc (and among others musl) are nicely runnable on NetBSD and have the > addditional advantage not to be bound to a certain version of the kernel. > > This of course is not valid if someone wants to build _NetBSD_ with tcc. > This sadly blocks building code on NetBSD (or with NetBSD libc). Certainly there is an option to use a 3rd party libc for TCC.. but this is now what I would like to pay for using a new compiler. This makes pretty high requirement for smaller compilers, including 8cc. They currently aren't usable. Researching the build of the NetBSD kernel and userland with TCC would be possible, once requirements will be met. I'm pretty sure that if TCC would produce valid NetBSD base system and get maintenance, we could discuss attaching TCC to NetBSD releng buildservers (at least for x86). >> Certain things cannot be reliably done in a portable way in libc, like >> alloca(3). > > A good point. Some things should not be the business of libc. > > IMHO stdarg.h is the compiler business, not a libc concern, > but the policy you present is yours, not mine. Ok. > > Thanks for the answer Kamil! > FreeBSD went another way to restore x86 stdarg.h to appease TCC... but they don't much care about !x86 targets, in NetBSD this isn't a viable option. > Regards, > Rune > > > ___ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > signature.asc Description: OpenPGP digital signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
On Fri, May 12, 2017 at 08:17:34PM +0200, Kamil Rytarowski wrote: > >> NetBSD libc has hard requirement on __builtin_va_list (or some > >> equivalent builtin). Without it, we cannot use TCC on NetBSD. > > > > Would you elaborate in which way the requirement is "hard"? > > We require C and C++ compilers that ship with popular extensions on par > with GCC. > > Old va_list has been retired with the following commit: > > https://github.com/NetBSD/src/commit/9735e84a7821b8a9cc42139d798ee188c4dd9368 > > This restricts NetBSD to GCC, Clang, PCC and perhaps ICC. > We set minimum reasonable set of features mandatory in the toolchain. I would say you make it harder to build with other toolchains but unsupported is still not impossible. OTOH there is probably little motivation to insist on a "native" tcc toolchain on NetBSD, because Linux binaries buildable under NetBSD with tcc (and among others musl) are nicely runnable on NetBSD and have the addditional advantage not to be bound to a certain version of the kernel. This of course is not valid if someone wants to build _NetBSD_ with tcc. > Certain things cannot be reliably done in a portable way in libc, like > alloca(3). A good point. Some things should not be the business of libc. IMHO stdarg.h is the compiler business, not a libc concern, but the policy you present is yours, not mine. Ok. Thanks for the answer Kamil! Regards, Rune ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
On 12.05.2017 18:00, u-j...@aetey.se wrote: > On Fri, May 12, 2017 at 05:19:15PM +0200, Kamil Rytarowski wrote: >> On 11.05.2017 21:53, avih wrote: >>> by providing the intrinsics (__builtin_va*) >>> musl relies on __builtin_va_list and the likes >> >> NetBSD libc has hard requirement on __builtin_va_list (or some >> equivalent builtin). Without it, we cannot use TCC on NetBSD. > > Would you elaborate in which way the requirement is "hard"? > We require C and C++ compilers that ship with popular extensions on par with GCC. Old va_list has been retired with the following commit: https://github.com/NetBSD/src/commit/9735e84a7821b8a9cc42139d798ee188c4dd9368 This restricts NetBSD to GCC, Clang, PCC and perhaps ICC. > An implementation of va_list is not itself a part of the calling > conventions, it should be possible to use whatever mechanics the compiler > chooses, builtins, macros or inlined/static functions. > > Is the limitation like "no support to avoid a certain definition of > va_list which is hidden inside the standard includes"? Then in theory > it could still be worked around, by using a modified copy of up to > all the system includes (which would be not pretty but possible). > We set minimum reasonable set of features mandatory in the toolchain. Certain things cannot be reliably done in a portable way in libc, like alloca(3). Old port of TCC used to... pretend to be lint(1). This verification tool has relaxed requirements in our headers. We won't reintroduce any fallbacks to libc other than __tcc_va_list or similar. > Regards, > Rune > > > ___ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel > signature.asc Description: OpenPGP digital signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
On Fri, May 12, 2017 at 05:19:15PM +0200, Kamil Rytarowski wrote: > On 11.05.2017 21:53, avih wrote: > > by providing the intrinsics (__builtin_va*) > > musl relies on __builtin_va_list and the likes > > NetBSD libc has hard requirement on __builtin_va_list (or some > equivalent builtin). Without it, we cannot use TCC on NetBSD. Would you elaborate in which way the requirement is "hard"? An implementation of va_list is not itself a part of the calling conventions, it should be possible to use whatever mechanics the compiler chooses, builtins, macros or inlined/static functions. Is the limitation like "no support to avoid a certain definition of va_list which is hidden inside the standard includes"? Then in theory it could still be worked around, by using a modified copy of up to all the system includes (which would be not pretty but possible). Regards, Rune ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
On 11.05.2017 21:53, avih wrote: > by providing the intrinsics (__builtin_va*) > musl relies on __builtin_va_list and the likes NetBSD libc has hard requirement on __builtin_va_list (or some equivalent builtin). Without it, we cannot use TCC on NetBSD. signature.asc Description: OpenPGP digital signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
On Fri, May 12, 2017 at 08:40:11AM +, avih wrote: > [3] discussion about tcc's stdarg.h: > dalias: so tcc now works with musl. i still have an issue though if > stdio.h (possibly others too) come before stdarg.h in the program. tcc has > its own prioritized include dirs with stdarg.h. i'm trying to figure out > musl's expectations with regards to this. i'm looking at bits/alltypes.h, > does musl expects the compiler to have an intrinistic define of > __DEFINED_va_list or __DEFINED___isoc_va_list ? FWIIW you can also look at the same kind of discussion I had with with Rich Felker (dalias) in http://www.openwall.com/lists/musl/2014/08/15/8 The "implicit -D__DEFINED_va_list" hack works for Pcc with musl, at least on i386. I do not seem to need any such tweak for tcc+musl on i386 but otoh did not test with the latest versions. Tcc on x86_64 had to use "-D__DEFINED_va_list -D__isoc_va_list=va_list -D__DEFINED___isoc_va_list". Cheers, Rune ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
> Le 7 mai 2017 à 08:16, Michael Matz a écrit : > > On debain, if you have libc6-dev and musl-dev installed you get a strange mix > of glibc and musl objects and shared libraries linked into the exe. E.g. in > the above it picks up /usr/lib/x86_64-linux-gnu/libc.a (from glibc), which > has TPOFF32 relocs and those aren't handled by TCC. > > Removing libc6-dev, installing musl-tools, and using musl-gcc for compilation > ensures that there's no mixture at least. But that then fails because TCC > itself isn't prepared to look into e.g. /usr/include/x86_64-linux-musl for > standard headers like e.g. stdio.h, neither does it look into > /usr/lib/x86_64-linux-musl/ for startup files like crt1.o. So, yeah, the > detection/support of musl is early and doesn't work with the split-mind > approach that debian is using. > > It does work for the setup of musl as the main libc, like with alpine linux; > so I'm not sure the detection should be disabled or rather be improved (or > there should perhaps be a configure option to override the detection by > users). To address that, I committed a first patch on mob to improve musl or uclibc detection: Now, configure does not enable musl or uclibc native support if a GNU linker is already present. This avoids interference for example on a Debian platform with musl-dev installed. More work is required to select musl libc in that case, with additional configure flags, i.e. --enable-musl and further code in tcc.h etc. Thanks, Marc ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
Michael - On Sun, May 07, 2017 at 08:16:08AM +0200, Michael Matz wrote: > On debian, if you have libc6-dev and musl-dev installed you get a > [mess that doesn't work with tinycc]. > So, yeah, the detection/support of musl > is early and doesn't work with the split-mind approach that debian > is using. > > It does work for the setup of musl as the main libc, like with > alpine linux; so I'm not sure the detection should be disabled or > rather be improved (or there should perhaps be a configure option to > override the detection by users). OK, sounds good, as long as improving the test results in it being disabled by default in debian and similar systems. I'd hate to see noobs discouraged from using this otherwise really nice code base by broken-ness caused by a false-positive musl detector. > >gcc-4.7.4/gcc/c-family/c-opts.c:141: error: ';' expected (got "=") > Yeah, thanks for finding the cause downthread. extern file-scope > declarations with initializer are questionable style but indeed > allowed by the standard, i.e. the above rejection is a bug in TCC. > Fixed in mob. Confirmed, awesome, thanks! - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
Hi, On Sat, 6 May 2017, Larry Doolittle wrote: Micheal, Marc, and tinycc lurkers - On Sun, May 07, 2017 at 04:54:38AM +0200, Michael Matz wrote: On Thu, 20 Apr 2017, Marc Vertes wrote: I just committed the patch to support musl-libc in the tcc compiler development branch: http://repo.or.cz/w/tinycc.git [...] Dear tinycc developers, let me know if this feature can be added to the upcoming 0.9.27 version, and also how to fix the DLL bootstrap problem. Fixed in mob. The problem is the stricter dynamic loader of musl, which ignores all STB_LOCAL symbols for symbol resolution [...] With that the tests also run on musl. [...] On Debian Jessie amd64 with musl-dev installed, tinycc (commit 5732a188) detects that musl exists (CONFIG_musl=yes in config.mak), builds OK, but fails on make test at dlltest: ./tcc2 -B.. -I/home/larry/git/tinycc/include -I/home/larry/git/tinycc -I.. -DCONFIG_TRIPLET="\"x86_64-linux-gnu\"" -DTCC_TARGET_X86_64 -DTCC_MUSL -DONE_SOURCE -run /home/larry/git/tinycc/tcc.c -B.. -I/home/larry/git/tinycc/include -I/home/larry/git/tinycc -I.. -run /home/larry/git/tinycc/examples/ex1.c /usr/lib/x86_64-linux-gnu/libc.so:2: error: unrecognized file type tcc: error: Unknown relocation type: 23 On debain, if you have libc6-dev and musl-dev installed you get a strange mix of glibc and musl objects and shared libraries linked into the exe. E.g. in the above it picks up /usr/lib/x86_64-linux-gnu/libc.a (from glibc), which has TPOFF32 relocs and those aren't handled by TCC. Removing libc6-dev, installing musl-tools, and using musl-gcc for compilation ensures that there's no mixture at least. But that then fails because TCC itself isn't prepared to look into e.g. /usr/include/x86_64-linux-musl for standard headers like e.g. stdio.h, neither does it look into /usr/lib/x86_64-linux-musl/ for startup files like crt1.o. So, yeah, the detection/support of musl is early and doesn't work with the split-mind approach that debian is using. It does work for the setup of musl as the main libc, like with alpine linux; so I'm not sure the detection should be disabled or rather be improved (or there should perhaps be a configure option to override the detection by users). I just made a quick attempt to build gcc-4.7.4 with current git tcc. It made it through about 337 compiles before failing on ../.././gcc/c-family/c-opts.c:141: error: ';' expected (got "=") Yeah, thanks for finding the cause downthread. extern file-scope declarations with initializer are questionable style but indeed allowed by the standard, i.e. the above rejection is a bug in TCC. Fixed in mob. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
On Sat, May 06, 2017 at 08:54:45PM -0700, Larry Doolittle wrote: > I just made a quick attempt to build gcc-4.7.4 with current git tcc. > It made it through about 337 compiles before failing on > ../.././gcc/c-family/c-opts.c:141: error: ';' expected (got "=") Removing the bogus "extern" in that line makes the build progress quite far, enough to build and start running the first-stage gcc. The build fault that eventually occurs looks like it has nothing to do with tcc. I'd leave tcc alone, and just patch that bogus gcc source. The behavior difference between gcc and tcc simplifies to: $ cat ext_init.c extern const unsigned int c_family_lang_mask = 1; $ gcc -c ext_init.c ext_init.c:1:27: warning: ‘c_family_lang_mask’ initialized and declared ‘extern’ extern const unsigned int c_family_lang_mask = 1; ^ $ echo $? 0 $ tcc -c ext_init.c ext_init.c:1: error: ';' expected (got "=") $ echo $? 1 - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
Micheal, Marc, and tinycc lurkers - On Sun, May 07, 2017 at 04:54:38AM +0200, Michael Matz wrote: > On Thu, 20 Apr 2017, Marc Vertes wrote: > >I just committed the patch to support musl-libc in the tcc > >compiler development branch: http://repo.or.cz/w/tinycc.git > > [...] > >Dear tinycc developers, let me know if this feature can be added > >to the upcoming 0.9.27 version, and also how to fix the DLL > >bootstrap problem. > Fixed in mob. The problem is the stricter dynamic loader of musl, > which ignores all STB_LOCAL symbols for symbol resolution [...] > With that the tests also run on musl. [...] On Debian Jessie amd64 with musl-dev installed, tinycc (commit 5732a188) detects that musl exists (CONFIG_musl=yes in config.mak), builds OK, but fails on make test at dlltest: ./tcc2 -B.. -I/home/larry/git/tinycc/include -I/home/larry/git/tinycc -I.. -DCONFIG_TRIPLET="\"x86_64-linux-gnu\"" -DTCC_TARGET_X86_64 -DTCC_MUSL -DONE_SOURCE -run /home/larry/git/tinycc/tcc.c -B.. -I/home/larry/git/tinycc/include -I/home/larry/git/tinycc -I.. -run /home/larry/git/tinycc/examples/ex1.c /usr/lib/x86_64-linux-gnu/libc.so:2: error: unrecognized file type tcc: error: Unknown relocation type: 23 where $ cat /usr/lib/x86_64-linux-gnu/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ OUTPUT_FORMAT(elf64-x86-64) GROUP ( /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc_nonshared.a AS_NEEDED ( /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 ) ) $ My personal recommendation is to disable musl detection in an 0.9.27 release, if that happens anytime soon. Other than the teething problems with musl support, the rest of tinycc works like a champ for me. The contrast between tinycc and gcc is astounding. I can build a tcc binary faster than I can unpack gcc-4.7.4 sources. I have long-term interest in tcc for use in diverse-double-compiling. I just made a quick attempt to build gcc-4.7.4 with current git tcc. It made it through about 337 compiles before failing on ../.././gcc/c-family/c-opts.c:141: error: ';' expected (got "=") - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
Hi, On Thu, 20 Apr 2017, Marc Vertes wrote: I just committed the patch to support musl-libc in the tcc compiler development branch: http://repo.or.cz/w/tinycc.git I tested the patch on alpine-linux x86_64. Beside disabled bound checking, everything works so far, except the dlltest target test, meaning that tcc can not yet bootstrap itself using shared library. I think that tcc is a perfect match for musl and simple small and fast platforms like alpine-linux. Dear tinycc developers, let me know if this feature can be added to the upcoming 0.9.27 version, and also how to fix the DLL bootstrap problem. Fixed in mob. The problem is the stricter dynamic loader of musl, which ignores all STB_LOCAL symbols for symbol resolution (and hence can't resolve relocs against those). Local symbols can always be resolved statically, but TCC didn't do that (easier to code), and it was harmless on e.g. glibc loader. But it always was suboptimal, so this was a good opportunity to extend this in TCC. With that the tests also run on musl. Take note that the default diff on alpine linux (the busybox one) doesn't support the -I option which is used in the preprocessor testsuite of TCC, so for completely clean results you need a different diff in $PATH. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
On Mon, Apr 24, 2017 at 10:12 AM, avih wrote: > Because you asked so nice, here's a less than 5 minutes guide to get enough > musl for tcc on Alpine linux, and without any permanent storage: > > - Download the "VANILLA" iso (80M) from https://alpinelinux.org/downloads/ > - Boot as live cd in a [V]M with network. No HDD required, 512M ram is > enough* > > - Login as root (no password) > - "echo \n\n\n | setup-interfaces" (or do manual setup) > - "ifup eth0" > - "echo 1 | setup-apkrepos" (or run it directly and choose manually) > - "apk add build-base git" to get some build deps (but not for the docs) > > That's enough to clone the tinycc repo, build it and run the tests, but > that's > without the doc tools. > > [*] 256M is probably enough if you don't install git, and you might need > more > if you add more tools like openssh or vim, or xfce4 etc ;) > > Of course, if instead of using it as live cd you to install it someplace > then 256M should be enough for quite a lot. While that's helpful if someone wants to reproduce, it doesn't describe the problem at all. -- -Austin GPG: 14FB D7EA A041 937B ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Add support of musl-libc to tinycc
Marc Vertes wrote: Hello, I just committed the patch to support musl-libc in the tcc compiler development branch: http://repo.or.cz/w/tinycc.git I tested the patch on alpine-linux x86_64. Beside disabled bound checking, everything works so far, except the dlltest target test, meaning that tcc can not yet bootstrap itself using shared library. I think that tcc is a perfect match for musl and simple small and fast platforms like alpine-linux. Dear tinycc developers, let me know if this feature can be added to the upcoming 0.9.27 version, All commits on mob will be part of the upcoming soon 0.9.27 release (unless reverted until then) and also how to fix the DLL bootstrap problem. For those who don't have a musl, you might describe what the problem is. Thanks, -- gr Many thanks, Marc ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Add support of musl-libc to tinycc
Hello, I just committed the patch to support musl-libc in the tcc compiler development branch: http://repo.or.cz/w/tinycc.git I tested the patch on alpine-linux x86_64. Beside disabled bound checking, everything works so far, except the dlltest target test, meaning that tcc can not yet bootstrap itself using shared library. I think that tcc is a perfect match for musl and simple small and fast platforms like alpine-linux. Dear tinycc developers, let me know if this feature can be added to the upcoming 0.9.27 version, and also how to fix the DLL bootstrap problem. Many thanks, Marc ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
