This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: configure patches for FreeBSD to support >1 architecture


In article <19990421172748.A4853@dragon.nuxi.com> you write:
>Sorry, here is a minor update of my FreeBSD patches.
>+/* Place spaces around this string.  We depend on string splicing to produce
>+   the final CPP_PREDEFINES value.  */
>+#define CPP_FBSD_PREDEFINES " -Dunix -D__FreeBSD__ -Asystem(unix)
>-Asystem(FreeBSD) "
>+


This won't get through.... These files have to be readable by an old K&R
compiler. Makes little sense, since this is compiled by gcc, or by a
first-stage cross, at least, but that's the current party-line.
I don't remember the topic off-hand, but I asked for something similar in
OpenBSD, and there is a discussion in the egcs ml archive.
Yep, this is a headache. Yep, this leads to some duplication.

Also, unless this is already set in stone, can you use names such as 
FBSD_CPP_PREDEFINES... would look slightly better, and OpenBSD uses
OBSD_* for a naming convention.


>+/* Provide a LIB_SPEC appropriate for FreeBSD.  Just select the appropriate
>+   libc, depending on whether we're doing profiling. 
>+   (like the default, except no -lg, and no -p.  */
>+#undef LIB_SPEC
>+#define LIB_SPEC
>"%{!shared:%{!pg:%{!pthread:%{!kthread:-lc}%{kthread:-lpthread
>-lc}}%{pthread:-lc_r}}%{pg:%{!pthread:%{!kthread:-lc_p}%{kthread:-lpthread_p
>-lc_p}}%{pthread:-lc_r_p}}}"

Iick! you can probably get something simpler. I can't even parse that one
properly. If this is just getting to the right C library, that spec processes
strings, so you can say: okay, link with -lpthread(add _p if pg) for kthread,
and always with -lc(add _r is if pthread)(add _p if pg)

How does your stuff work for shared ?

>+/* Use more efficient ``thunks'' to implement C++ vtables. */
>+#undef DEFAULT_VTABLE_THUNKS
>+#define DEFAULT_VTABLE_THUNKS 1

I'm not sure you want this... there is a bug in C++ that still isn't fixed,
as far as I know. If this is already in, congrats, you have the bug, and no
easy binary compatible way to get rid of it.

I think that the idea is that ALL platforms are going VTABLE_THUNKS when
this bug is fixed, and this will probably be folded with all the new C++ ABI
changes.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]