Re: [PATCH] orbit-config.in + gcc-3.0

[<dahaverk rockwellcollins com>]

And not only is auto-matic inclusion of -I/usr/include bad for GCC 3.0.  It
can be a source of problems
when cross-compiling.

I am currently thinking about what way might make the best sense for taking
care of the "glib" dependancies
so that I can cross_compile to LynxOS.

I haven't built GCC 3.0 yet,  But another consideration is when
(developers) compile a new version of the
compiler, and install it in an alternate directory  automatic inclusion of
the HOST includes may be problem-matic.
Since I don't have "Sys-Admin" privilages on my Solaris box...  This is
often the only way I can us a new version
of the GCC immediately vs waiting for out IT dept to update things.   For
instance....   when I compile a newer
version of the GCC tools I usally install it in my Unix Home directory for
my use...   e.g.  /home/dave/gcc-3.0
So my preference is that whatever I compile to use the compiler
collection's install directories.

-Dave





Daniel Elstner <daniel.elstner@gmx.net>@gnome.org on 08/20/2001 11:02:42 AM

Please respond to orbit-list@gnome.org

Sent by:  orbit-list-admin@gnome.org


To:   orbit-list@gnome.org
cc:

Subject:  [PATCH] orbit-config.in + gcc-3.0


Hi,

here's a patch for orbit-config.in adding a test wether
$includedir = /usr/include, and omitting -I$includedir if
true.  The -I/usr/include would otherwise prevent almost
every C++ program from compiling with gcc-3.0.

If you're interested in the details why -I/usr/include
is a really bad idea, here are some pointers:

http://gcc.gnu.org/ml/gcc/2001-06/msg00948.html
http://www.geocrawler.com/lists/3/SourceForge/1110/75/6325952/

Regards,
--Daniel

(I'm not subscribed, so please CC to me. Thanks.)


(See attached file: orbit-config.in.patch)

orbit-config.in.patch