[opensuse-factory] LFS_CFLAGS injected into optflags
Quoting crrodriguez@opensuse.org:
home:elvigia:branches:GNOME:Factory/loudmouth -> GNOME:Factory/loudmouth
https://build.opensuse.org/request/show/181220
Description: - build with LFS_CFLAGS in 32 bit archs
Christian, Can you please, for general information on -factory, explain as to the 'why' you submit all those? I see many of them and of course also get the point.. but if they are that important: why not for 64bit systems? On all my systems I checked so far, this CFLAG is simply a waste and useless: getconf -a | grep -e "LFS.*_CFLAGS" LFS_CFLAGS LFS64_CFLAGS -D_LARGEFILE64_SOURCE => so LFS_CFLAGS is empty... why would I care to 'inject' it? If it's that important: why don't we have it in optflags in first place? I really don't like those additions without any explanation at ANY moment, including a reference what it does, how can the effects be tested, how can be tested if it's still needed.. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri 28 Jun 2013 02:43:34 AM CLT, Dominique Leuenberger a.k.a. Dimstar wrote:
Can you please, for general information on -factory, explain as to the 'why' you submit all those?
Oh dear lord, over 10 years has passed since large file support was added to glibc and I __STILL_ have to explain this ?
I see many of them and of course also get the point.. but if they are that important: why not for 64bit systems?
Because 64 bit systems are LFS by default.
I really don't like those additions without any explanation at ANY moment, including a reference what it does, how can the effects be tested, how can be tested if it's still needed..
Please read http://users.suse.com/~aj/linux_lfs.html and particulary this: http://ac-archive.sourceforge.net/largefile/ along with all associated links. (particularly the section "problems") -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Quoting Cristian Rodríguez
On Fri 28 Jun 2013 02:43:34 AM CLT, Dominique Leuenberger a.k.a. Dimstar wrote:
Can you please, for general information on -factory, explain as to the 'why' you submit all those?
Oh dear lord, over 10 years has passed since large file support was added to glibc and I __STILL_ have to explain this ?
yes... if you're that 'wise', you'd know that upfront.
I see many of them and of course also get the point.. but if they are that important: why not for 64bit systems?
Because 64 bit systems are LFS by default.
Sure.. so why don't you answer on the part that LFS_CFLAGS is empty while LFS64_CFLAGS is not? Looking at any system I ran across, you inject exactly nothing into the optflags using that getopt call.. and adding a NOP is useless in most cases.
I really don't like those additions without any explanation at ANY moment, including a reference what it does, how can the effects be tested, how can be tested if it's still needed..
Please read
http://users.suse.com/~aj/linux_lfs.html
and particulary this:
http://ac-archive.sourceforge.net/largefile/ along with all associated links. (particularly the section "problems")
right.. so I am safe in assuming that you verified the entire code where you inject those 'NOP' flags (still.. what for.. getopt LFS_CFLAGS is empty) and none of those problems listed can happen in current and future versions of the libraries? I am not willing to accept such things without at least test cases around those low-level libs! Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/28/2013 04:20 AM, Dominique Leuenberger a.k.a. Dimstar wrote:
Sure.. so why don't you answer on the part that LFS_CFLAGS is empty
LFS_CFLAGS is empty because the particular target does not need any particular preprocessor definition for the feature (i.e, enabled by default)
while LFS64_CFLAGS is not?
http://people.redhat.com/berrange/notes/largefile.html
right.. so I am safe in assuming that you verified the entire code where you inject those 'NOP' flags (still.. what for.. getopt LFS_CFLAGS is empty)
It is not empty in all 32 bit archs (i586, armv5, 6, 7 ppc32..) and none of those problems listed can happen in current and
future versions of the libraries?
Any problem future or present will show up anyway regardless of this change in x86_64. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/28/2013 04:33 AM, Cristian Rodríguez wrote:
On 06/28/2013 04:20 AM, Dominique Leuenberger a.k.a. Dimstar wrote:
Sure.. so why don't you answer on the part that LFS_CFLAGS is empty
LFS_CFLAGS is empty because the particular target does not need any particular preprocessor definition for the feature (i.e, enabled by default)
while LFS64_CFLAGS is not?
Note that this link is old.. but you get the idea LFS_CFLAGS = transparent, implicit LFS64_CFLAGS = explicit, the application needs to call *64 functions. see also feature_test_macros(7) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 2013-06-28 10:42, Cristian Rodríguez wrote:
Note that this link is old.. but you get the idea LFS_CFLAGS = transparent, implicit LFS64_CFLAGS = explicit, the application needs to call *64 functions. see also feature_test_macros(7)
I take it "properly behaving" software automatically uses -D$$large and won't need such spec hacks. Speaking of which, should not we just change %optflags to include $(getconf -a LFS_CFLAGS) so that we don't have to change oodles of .specs? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
"Dominique Leuenberger a.k.a. Dimstar"
On all my systems I checked so far, this CFLAG is simply a waste and useless:
getconf -a | grep -e "LFS.*_CFLAGS" LFS_CFLAGS LFS64_CFLAGS -D_LARGEFILE64_SOURCE
=> so LFS_CFLAGS is empty... why would I care to 'inject' it?
Try using an ILP32 environment. $ getconf -v POSIX_V7_ILP32_OFF32 LFS_CFLAGS -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (4)
-
Andreas Schwab -
Cristian Rodríguez -
Dominique Leuenberger a.k.a. Dimstar -
Jan Engelhardt