grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATH] grub-mkrelpath


From: rubisher
Subject: Re: [PATH] grub-mkrelpath
Date: Wed, 04 Nov 2009 10:55:48 +0100
User-agent: Scarlet Webmail

Felix,

On Tue, 03 Nov 2009 15:09:33 +0100, Felix Zielcke <address@hidden>
wrote:
> Am Dienstag, den 03.11.2009, 14:51 +0100 schrieb rubisher:
>> On Tue, 03 Nov 2009 11:33:42 +0100, Felix Zielcke <address@hidden>
>> wrote:
>> > Am Dienstag, den 03.11.2009, 11:21 +0100 schrieb rubisher:
>> >> Hello Felix,
>> >> 
>> >> On Mon, 02 Nov 2009 09:54:43 +0100, Felix Zielcke <address@hidden>
>> >> wrote:
>> >> > Am Sonntag, den 01.11.2009, 23:04 +0100 schrieb Robert Millan:
>> >> >> On Sun, Nov 01, 2009 at 04:39:42PM +0100, Felix Zielcke wrote:
>> >> >> > 
>> >> >> > I added now a comment that this shouldn't ever happen.
>> >> >> > 
>> >> >> > New version avaible at
>> >> >> > bzr+ssh://bzr.savannah.gnu.org/grub/people/fzielcke/mkrelpath
>> >> >> 
>> >> [snip]
>> >> 
>> >> I am trying to build your mkrelpath branch on my ppc with debian
>> gcc-4.4
>> >> latest unstable release 4.4.2-1 and failed to build as far as I
>> >> understand
>> >> because isystem syntax is not correct; following diff help me to
>> complete
>> >> the build:
>> > 
>> > Which is the same as in trunk.
>> right no issue to compile trunk 2676 but as following way (svn 2676):
> 
> Right trunk contains my -I($srcdir)/include fix.
> merged now.
Sorry I don't agree with your fix:

here is what I grab from gcc-4.4 manual online:
-isysroot dir
This option is like the --sysroot option, but applies only to header 
files. See the --sysroot option for more information.

--sysroot=dir
Use dir as the logical root directory for headers and libraries. For 
example, if the compiler would normally search for headers in /usr/include
and 
libraries in /usr/lib, it will instead search dir/usr/include and
dir/usr/lib.
If you use both this option and the ?-isysroot? option, then the --sysroot
option will apply to libraries, but the ?-isysroot? option will apply to 
header files.
The GNU linker (beginning with version 2.16) has the necessary support for
this option. If your linker does not support this option, the header file 
aspect of --sysroot will still work, but the library aspect will not.

as far as I understand, this spec doesn't says that 'dir' has some default
value so may be the precompiler issue here is that without --sysroot or
--isysroot cpp collect garbage as 'dir' and failed to work (sorry I don't
remember how to trace in detail gcc to proof my hypothesis) but following
patch actually works to me on your branches 1802 and latest 1803:
--- ./Makefile.in.orig  2009-11-04 07:20:46.000000000 +0000
+++ ./Makefile.in       2009-11-04 07:57:44.000000000 +0000
@@ -75,7 +75,7 @@
 TARGET_MODULE_FORMAT = @TARGET_MODULE_FORMAT@
 TARGET_APPLE_CC = @TARGET_APPLE_CC@
 OBJCONV = @OBJCONV@
-TARGET_CPPFLAGS = @TARGET_CPPFLAGS@ -isystem=$(srcdir)/include
-I$(srcdir)/include -I$(builddir) -I$(builddir)/include \
+TARGET_CPPFLAGS = @TARGET_CPPFLAGS@ -isysroot$(srcdir) -isystem=/include
-I$(builddir) -I$(builddir)/include \
        -Wall -W
 TARGET_LDFLAGS = @TARGET_LDFLAGS@
 TARGET_IMG_LDSCRIPT = @TARGET_IMG_LDSCRIPT@
=== <> ===


> But I still have the feeling using -isystem is wrong at all or at least
> the =.
Well as far as I understand, yes for cross-compiling that would make stuff
easier?

A quick look at linux kernel build, it shows that also use -isystem but
not yet with '=' option so may be my previous patch would be more relevant.

I let you appreciate.

Tx,
    J.

PS: any idea where (in which part of this proj) should I have a look to
learn why ofs doesn't reach to find disks and their structures?)










reply via email to

[Prev in Thread] Current Thread [Next in Thread]