interesting. i hadn't thought of going that way. i was afraid of non-obvious
breakage.
what do you do about inline? what do do you about asm? unfortunately a quick
grep of even the first level of /usr/include on linux shows some asm goo.
- erik
This is a discussion on Re: [9fans] Summer of Code: Call for mentors and students - Plan9 ; On Fri, Mar 16, 2007 at 09:12:37PM -0400, erik quanstrom wrote: >porting kenc to linux is doable, doesn't seem very useful, as >kenc doesn't do many of the stupid c compile tricks found >in linux heder files such as Actually, ...
On Fri, Mar 16, 2007 at 09:12:37PM -0400, erik quanstrom wrote:
>porting kenc to linux is doable, doesn't seem very useful, as
>kenc doesn't do many of the stupid c compile tricks found
>in linux heder files such as
Actually, it's more doable than you'd imagine. I've managed to get kencc
to compile objects against the FreeBSD C headers (I can't run them,
because I've no way to link them) by pushing something like this into
the preprocessor stream:
#define __extension__(foo)
#define __attribute__(foo)
#define __inline
#define __func__ "foo"
#define __va_list=va_list
typedef char* va_list
and feeding it through this:
grep -v '^[ ]*typedef.*va_list' | 9 sed 's/return \(\);/return;/g'
However, I think that a much better solution is to try to avoid using
system headers in most ported code. The Plan9Port headers have no such
gcc garbage, except inside a few ifdefs, and only, to my knowledge, for
the AUTOLIB() hack.
--
Kris Maglione
This space for rent.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.2 (FreeBSD)
iD8DBQFF+0SDseQZD8Aui4wRAhWNAKCSx6Ns+BhRslt8Cq0qdT 5IpeRTagCdG2zh
bi7XKN1TNkiKFGIO8Bw5zMc=
=d4ud
-----END PGP SIGNATURE-----
interesting. i hadn't thought of going that way. i was afraid of non-obvious
breakage.
what do you do about inline? what do do you about asm? unfortunately a quick
grep of even the first level of /usr/include on linux shows some asm goo.
- erik
On Fri, Mar 16, 2007 at 09:56:31PM -0400, erik quanstrom wrote:
>interesting. i hadn't thought of going that way. i was afraid of non-obvious
>breakage.
I'd considered it, but things like __^(extension attribute)^__ shouldn't
cause breakage. __alignment__ certainly could, and there are some ugly
ones, but the BSD headers are considerably cleaner than the glibc
headers, so I didn't have to deal with too much.
>what do you do about inline? what do do you about asm? unfortunately a quick
>grep of even the first level of /usr/include on linux shows some asm goo.
Well, in the BSD headers, at least, there's only one instance of __asm__
that appears outside of a macro, and that's in an FSF header that is
full of inline functions and all kinds of other such goo. I'll just have
to hope that nothing I need to compile includes itThe ones in the
macros obviously don't matter unless they're used.
--
Kris Maglione
If you can get to the faulty part, you don't have the
tool to get it off.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.2 (FreeBSD)
iD8DBQFF+08YseQZD8Aui4wRAjhcAJ9RfbuPhoCsDTh9VogSLI ZwkU2RTACfcNfW
2wpBPT6ngZSI7jE6dWrtWEw=
=BJuI
-----END PGP SIGNATURE-----