All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Brown <guruswami@orcon.net.nz>
To: xen-devel@lists.sourceforge.net
Subject: Re: Inheriting CFLAGS
Date: Tue, 16 Nov 2004 12:19:53 +1300	[thread overview]
Message-ID: <41993999.6050903@orcon.net.nz> (raw)
In-Reply-To: <E1CTpK2-0004af-00@mta1.cl.cam.ac.uk>

No, I do not have those lines in my Rules.mk file. It was downloaded 
this morning using the ebuild, so was the xen-2.0.tgz file from 
sourceforge. If I add -nopie to the CFLAGS in Rules.mk file xen will 
compile fine, however if I add -nopie to my environment CFLAGS it does 
not get picked up by the xen build script. Therefore I can compile and 
install it, but it takes manual intervention, which defeats the idea of 
using an ebuild :)

I am not looking of inheriting CFLAGS into the kernel build process - I 
agree that it is bad. However I am unable to build Xen-2.0 itself with 
my compiler. Unfortunately, unlike with GCC 3.4, it doesn't compile a 
non-SSP/PIE version of gcc to use. (I'm running gcc 3.3.4)

Keir Fraser wrote:
>>>I am attempting to install Xen-2.0 using the Gentoo Ebuilds written by Philip
>>>Taylor, and have run into the same problem as A Streecar Named with needing to
>>>implement the -nopie flag.
>>
>>strange, I didn't have to do it (using ebuilds from 
>>http://bugs.gentoo.org/show_bug.cgi?id=70161)
> 
> 
> Yes, I did wonder about this.
> 
> Can you take a look in xen/arch/x86/Rules.mk and see if you have the
> lines:
>  # Disable PIE/SSP if GCC supports them. They can break us.
>  CFLAGS  += $(call test-gcc-flag,-nopie)
>  CFLAGS  += $(call test-gcc-flag,-fno-stack-protector)
>  CFLAGS  += $(call test-gcc-flag,-fno-stack-protector-all)
> 
> If so then you have a *very* up-to-date tree. :-) I recently checked
> in a build fix that would disable PIE/SSP iff they are supported by
> GCC. 
> 
> If not then I'm confused!
> 
> 
>>>Is it possible to have Xen inherit these CFLAGS as a base, and then modify
>>>them as required? Part of the enthusiasm over Gentoo is the ability to
>>>customise and optimise the applications.
>>
>>If you're talking about kernel, I don't think it's a good idea. None of 
>>the packages under sys-kernel inherits CFLAGS from Portage's 
>>/etc/make.conf.
> 
> 
> Yeah, it's a bad idea! Kernels are very sensitive to compile flags
> -- both Xen and Linux use a wide range of GCC features and frequently
> use inline assembler, so the code is fragile when flags are changed
> from what we developers use. Allowing CFLAGS to be modified would be
> giving users a loaded gun. :-)
> 
>  -- Keir
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: InterSystems CACHE
> FREE OODBMS DOWNLOAD - A multidimensional database that combines
> robust object and relational technologies, making it a perfect match
> for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
> 
> 


-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8

  reply	other threads:[~2004-11-15 23:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-15 21:57 Inheriting CFLAGS Jerome Brown
2004-11-15 22:08 ` Jan Kundrat
2004-11-15 22:27   ` Keir Fraser
2004-11-15 23:19     ` Jerome Brown [this message]
2004-11-15 23:41       ` Philip Taylor
2004-11-16  0:01         ` Jerome Brown
2004-11-16  9:47           ` Keir Fraser
2004-11-16 18:57             ` Jerome Brown
2004-11-16 19:41               ` Keir Fraser
2004-11-16 21:32     ` Jan Kundrát
2004-11-16 23:53       ` A Streetcar Named
2004-11-17  1:44         ` Jerome Brown
2004-11-17  9:33         ` Jan Kundrat

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41993999.6050903@orcon.net.nz \
    --to=guruswami@orcon.net.nz \
    --cc=xen-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.