Re: typos
On Thu, 4 Jul 2013, Veres Lajos wrote: On Wed, 3 Jul 2013, Veres Lajos wrote: Around 99% of the typos are in comments and documentations a few of them are only in function/variable names (living code). I think it is not really history obtrusive. I will create a small subset for preview and send it for reviewing. (I would not do the whole before getting a green signal... It could take me at least 4-5 hours to review the whole patch...) http://lavela.hu/gcc.misspell-fixer.20130704.notrevised.patch.bz2 This is the patch generated by the misspell fixer script. (This is the patch against the whole tree.) I did NOT reviewed it yet. What do you think could it be usefull? Should I review the file? Probably I could remove some false positives, but I am not a C expert. The script could do with some improvements, but it would be good indeed to fix some of those typos. - the script creates non-words : suppresss - the script breaks good words : bellwether - most of the changes are in translation files where it breaks non-english text - most of the rest of the changes are in changelogs, which are not that useful to fix - the script does not respect the case (inserts some lowercase in the middle of all-uppercase sentences) I also believe you should separate comment/doc changes from code changes (which break the code in several places) and submit only the first category. Renaming variables with a typo in their name can be done separately (you can keep them in the same patch if you want, but you'll at least need to bootstrap the compiler to check for mistakes). Then you probably want to split the patch per directory for review, unless you can find a global maintainer willing to review the whole thing. Finally send a few of those to gcc-patches and see how it goes :-) Thanks, -- Marc Glisse
Strange Fortran/C/Java interaction
Hi, I'm not sure if this is a bug in gcc, or in Java, or maybe even a feature, so I'm asking for opinion here before opening a PR... The attached testcase requires gcc and gfortran, as well as a JDK installation. When running "make" with gcc/gfortran 4.7.2 and Oracle JDK 1.7, a single call to JNI_CreateJavaVM() changes the behaviour of subsequent READ statements in the Fortran code, depending on the value of the LC_ALL environment variable. If this is a bug (it certainly feels like one to me), do you think it is fixable in either gcc or the Java libraries, or is this some unfortunate interaction that cannot really be fixed? If there is something that can be done in gcc, I'll be happy to open a full bug report. Cheers, Martin Output of "make" on my local machine for reference: rm -f *.o testcase *~ gcc -I/opt/java/jdk7/include -I/opt/java/jdk7/include/linux -c testcase_c.c gfortran -c testcase_f.f90 gfortran -o testcase testcase_c.o testcase_f.f90 -L/opt/java/jdk7/jre/lib/amd64/server -ljvm running with LC_ALL=C before JVM creation: result= 2.7260 after JVM creation: result= 2.7260 running with LC_ALL=POSIX before JVM creation: result= 2.7260 after JVM creation: result= 2.7260 running with LC_ALL=de_DE before JVM creation: result= 2.7260 after JVM creation: result= 2. testcase.tgz Description: Binary data
Re: typos
On 4 July 2013 08:20, Marc Glisse wrote: > > The script could do with some improvements, but it would be good indeed to > fix some of those typos. > > - the script creates non-words : suppresss Yes, I noticed "functino" being changed to "functiono" :-) > I also believe you should separate comment/doc changes from code changes > (which break the code in several places) and submit only the first category. The only valid changes to libstdc++-v3 files are in comments and documentation, but they are valid so I'm going to fix them later today, thanks for reporting them.
Re: Question on register renaming in rtl loop unroll pass
On Fri, Jun 28, 2013 at 6:39 PM, Eric Botcazou wrote: >> The problem is auto-inc-dec is weak and can only capture >> post-increment in first part of code, generating even worse code for >> RA: >> .L1: >> r197 <- r162 >> [r197++] <- x >> ... >> [r162+4] <- y >> r162 <- r197+0x4 >> ... >> b .L1 >> Now we have two live registers and it seems hard to eliminate. >> >> So could the unrolled codes be like below? > > I'd try the opposite first, i.e to do more renaming so as to get smaller live > ranges for the pseudo-registers and thus help the auto-inc-dec and RA passes. Hi Eric, Thanks for your explanation. It seems the unroller tends to replace: use(i) i = i + 1; ... use(i) i = i + 1; ... use(i) i = i + 1; ... type of codes by: use(i) i0 = i + 1 ... use(i) i = i0 + 1 ... use(i) i = i0 + 2 ... I understand this splits long live range of "i" into short ones, but since we have -fweb pass which does below transformation: use(i) i = i + 1; ... use(i) i = i + 1; ... use(i) i = i + 1; ... into: use(i) i0 = i + 1 ... use(i0) i1 = i0 + 1 ... use(i1) i = i0 + 2 ... Why would we want "-fsplit-ivs-in-unroller" in the first place? As far as live range is concerned, it seems "-fweb" works as good as "-fsplit-ivs-in-unroller". Thanks in advance. -- Best Regards.
Re: Strange Fortran/C/Java interaction
On 07/04/2013 11:22 AM, Martin Reinecke wrote: The attached testcase requires gcc and gfortran, as well as a JDK installation. When running "make" with gcc/gfortran 4.7.2 and Oracle JDK 1.7, a single call to JNI_CreateJavaVM() changes the behaviour of subsequent READ statements in the Fortran code, depending on the value of the LC_ALL environment variable. Can you reproduce this with OpenJDK 7? -- Florian Weimer / Red Hat Product Security Team
Re: Strange Fortran/C/Java interaction
On 07/04/13 13:43, Florian Weimer wrote: > On 07/04/2013 11:22 AM, Martin Reinecke wrote: >> The attached testcase requires gcc and gfortran, as well as a JDK >> installation. When running "make" with gcc/gfortran 4.7.2 and >> Oracle JDK 1.7, a single call to JNI_CreateJavaVM() changes the >> behaviour of subsequent READ statements in the Fortran code, >> depending on the value of the LC_ALL environment variable. > > Can you reproduce this with OpenJDK 7? Oops, I probably used the wrong name... I tested with the JDK that comes by default with OpenSUSE 12.3, which should actually be OpenJDK 7. Cheers, Martin
Re: Strange Fortran/C/Java interaction
On 07/04/2013 01:55 PM, Martin Reinecke wrote: On 07/04/13 13:43, Florian Weimer wrote: On 07/04/2013 11:22 AM, Martin Reinecke wrote: The attached testcase requires gcc and gfortran, as well as a JDK installation. When running "make" with gcc/gfortran 4.7.2 and Oracle JDK 1.7, a single call to JNI_CreateJavaVM() changes the behaviour of subsequent READ statements in the Fortran code, depending on the value of the LC_ALL environment variable. Can you reproduce this with OpenJDK 7? Oops, I probably used the wrong name... I tested with the JDK that comes by default with OpenSUSE 12.3, which should actually be OpenJDK 7. What happens is that the JVM initialization in JNI_CreateJavaVM() calls setlocate. This seems to change the behavior of READ. I don't know enough about gfortran to judge whether READ should follow the libc locale or not. -- Florian Weimer / Red Hat Product Security Team
Re: Strange Fortran/C/Java interaction
On 07/04/13 14:09, Florian Weimer wrote: > What happens is that the JVM initialization in JNI_CreateJavaVM() calls > setlocate. This seems to change the behavior of READ. I don't know enough > about gfortran to judge whether READ should follow the libc locale or not. All I can say is that I don't observe the same behavior when calling JNI_CreateJavaVM() from C++ (using stringstreams for the string->double conversion) - so it seems that the C++ standard library doesn't follow the libc locale. Cheers, Martin
Re: Git mirror: asan branch
Hi! On Wed, 3 Jul 2013 09:54:58 -0700, Jason Merrill wrote: > On 07/03/2013 02:47 AM, Thomas Schwinge wrote: > > OK, that of course works, but from the wiki page I got the idea that it > > explicitly was meant to merge these together. So assuming this used to > > work in the past, I wonder what so that it no longer does; such as Git > > allowing such duplicates merging in the past, and/or was the intersection > > of refs/remotes/* and refs/heads/* meant to be the empty set (then I > > assume the merging would work, too), but no longer is? > > Hmm, it looks like I wrote that up without actually doing it myself, > oops. I'll correct the wiki. Hmm, seems the change you've done: fetch = refs/heads/*:refs/remotes/origin/* fetch = refs/remotes/*:refs/remotes/origin/remotes/* ..., is not ideal either: using »git fetch --verbose --prune« I now see all the refs being downloaded -- and then immediatelly pruned again. :-/ Would the following be an appropriate variant? Seems to work fine, but "disturbs" the regular Git refs namespace a bit? fetch = refs/heads/*:refs/remotes/upstream/* fetch = refs/remotes/*:refs/remotes/upstream-remotes/* Grüße, Thomas pgp_6ETin3ETl.pgp Description: PGP signature
Re: typos
Hi, On Thu, Jul 04, 2013 at 04:43:00AM +0200, Veres Lajos wrote: > On Wed, 3 Jul 2013, Veres Lajos wrote: > > > Around 99% of the typos are in comments and documentations a few of them > > are only in function/variable names (living code). > > I think it is not really history obtrusive. > > > > I will create a small subset for preview and send it for reviewing. > > (I would not do the whole before getting a green signal... It could take > > me at least 4-5 hours to review the whole patch...) > > http://lavela.hu/gcc.misspell-fixer.20130704.notrevised.patch.bz2 > This is the patch generated by the misspell fixer script. > (This is the patch against the whole tree.) > I did NOT reviewed it yet. > What do you think could it be usefull? Should I review the file? > Probably I could remove some false positives, but I am not a C expert. I'd just ignore all ChangeLog files, nobody will want to spend time reviewing changes in them. It may be even a bad idea. I think your patch also includes a lot of other file types (e.g. *.po) which I'm not sure you want to touch. So I'd suggest that for your first proposal you pick fixes in a dozen or so .c and/or .h files, prepare a patch modifying just these files, check the changes manually, submit the patch and see what happens :-) I cannot approve anything but I certainly appreciate your effort. And I think that fixing typos in the documentation files will definitely be appreciated by everyone. Thanks, Martin
Re: Strange Fortran/C/Java interaction
Martin Reinecke wrote: > > The attached testcase requires gcc and gfortran, as well as a JDK > installation. When running "make" with gcc/gfortran 4.7.2 and > Oracle JDK 1.7, a single call to JNI_CreateJavaVM() changes the > behaviour of subsequent READ statements in the Fortran code, > depending on the value of the LC_ALL environment variable. > > If this is a bug (it certainly feels like one to me), do you think > it is fixable in either gcc or the Java libraries, or is this > some unfortunate interaction that cannot really be fixed? > If there is something that can be done in gcc, I'll be happy to open > a full bug report. It sounds like the following bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 libgfortran calls libc's strtof/strtod/strtold/libquadmath's strtoflt128 to convert the number. And that function is locale dependent - but gfortran assumes that it uses a "." as decimal separator. It's surely fixable - the question is only what's the best approach. I see the following possibilities: - Ignore the issue (not the best approach but the simplest. Also known as: The compiler user has to handle it.) - libgfortran should have its own parsing of the string. - (Temporarily) reset the local setting before calling strtof/strtod/strtold/libquadmath - Convert the input to the used locale before calling strtof/strtod/strtold/libquadmath I am in favour of the last option. The first one is the best current solution for you (sorry!): Handle the locale issue it yourself. Tobias
haifa-scheduler marks instructions having TRUE dependencies as an ANTI dependencies.
Hi all, It seems that sometimes haifa-scheduler assigns ANTI dependency for the instructions having TRUE dependency. I observed it happening in case of basic block as following: <32 memory load/store rtx> rtx_1: store to memory rtx_2: load from memory I1 and i2 will have ANTI dependency instead of TRUE dependency. Once the sizes of pending_read_insns and pending_write_insns is bigger than MAX_PENDING_LIST_LENGTH (32) the sched_analyze_1 does flush_pending_lists thus putting current insn (rtx_1 in this example) to the last_pending_memory_flush list. During the analysis of the next rtx (rtx_2 in the example) sched_analyze_2 marks rtx_1 and rtx_2 as having ANTI dependence. This is done in sched-deps.c:2652 by the following code: for (u = deps->last_pending_memory_flush; u; u = XEXP (u, 1)) add_dependence (insn, XEXP (u, 0), REG_DEP_ANTI); I have few questions with this regard: 1. Is my understanding correct? 2. If it is what is the reason for this behavior? 3. What should I do in the cost_adjust hook if I want to distinguish between two cases (TRUE and ANTI dependency). In my target the cost for anti-dependency is 0, and cost for the true dependency 1 or bigger. BR, Viktor.
Re: Strange Fortran/C/Java interaction
Hi Tobias! >> The attached testcase requires gcc and gfortran, as well as a JDK >> installation. When running "make" with gcc/gfortran 4.7.2 and >> Oracle JDK 1.7, a single call to JNI_CreateJavaVM() changes the >> behaviour of subsequent READ statements in the Fortran code, >> depending on the value of the LC_ALL environment variable. >> >> If this is a bug (it certainly feels like one to me), do you think >> it is fixable in either gcc or the Java libraries, or is this >> some unfortunate interaction that cannot really be fixed? >> If there is something that can be done in gcc, I'll be happy to open >> a full bug report. > > It sounds like the following bug: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 Yes, I found that one too in the meantime :) > libgfortran calls libc's strtof/strtod/strtold/libquadmath's strtoflt128 > to convert the number. And that function is locale dependent - but > gfortran assumes that it uses a "." as decimal separator. > > It's surely fixable - the question is only what's the best approach. I > see the following possibilities: > > - Ignore the issue (not the best approach but the simplest. Also known > as: The compiler user has to handle it.) > - libgfortran should have its own parsing of the string. > - (Temporarily) reset the local setting before calling > strtof/strtod/strtold/libquadmath > - Convert the input to the used locale before calling > strtof/strtod/strtold/libquadmath > > I am in favour of the last option. The first one is the best current > solution for you (sorry!): Handle the locale issue it yourself. For me that's absolutely fine - now that I understand what happens. The problem is that for someone who has just noticed that their program behaves strangely it is _extremely_ hard to find the real reason. (In our case, it turned up after upgrading from JDK 1.6 to 1.7.) It would be very worthwhile to save other people this pain, so I would be glad if one of the other solutions could be be implemented. Maybe some code can be taken from libstdc++ ... things seem to work as expected there. Cheers, Martin
Re: Strange Fortran/C/Java interaction
On Thu, 4 Jul 2013, Tobias Burnus wrote: > It sounds like the following bug: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 > > libgfortran calls libc's strtof/strtod/strtold/libquadmath's strtoflt128 > to convert the number. And that function is locale dependent - but > gfortran assumes that it uses a "." as decimal separator. > > It's surely fixable - the question is only what's the best approach. I > see the following possibilities: > > - Ignore the issue (not the best approach but the simplest. Also known > as: The compiler user has to handle it.) > - libgfortran should have its own parsing of the string. > - (Temporarily) reset the local setting before calling > strtof/strtod/strtold/libquadmath > - Convert the input to the used locale before calling > strtof/strtod/strtold/libquadmath * On systems using glibc, use the functions such as strtod_l that take an explicit locale argument. -- Joseph S. Myers jos...@codesourcery.com
PR57792 fixincludes doesn't honor the use of --with-sysroot during bootstrap
Bruce, While bootstrapping darwin without the SDK (aka /usr/include) being present in /, I discovered the latent defect that fixincludes/fixinc.in doesn't honor the use of the --with-sysroot configure option and blindly uses the headers in /usr/include. The code in fixincludes needs some mechanism to obtain the DIR passed to configure's --with-sysroot option and, if that configure option was used, the hardcoded /usr/include in fixinclude/fixincl.in needs to use DIR/usr/include instead at... # # # # # # # # # # # # # # # # # # # # # # # Search each input directory for broken header files. # This loop ends near the end of the file. # if test $# -eq 0 then INPUTLIST="/usr/include" else INPUTLIST="$@" fi Currently I am forced to manually patch fixincludes/fixinc.in to have the DIR passed to --with-sysroot honored during the bootstrap. Thanks in advance for any help in getting this oversight in fixincludes fixed for gcc 4.9. Jack
Re: PR57792 fixincludes doesn't honor the use of --with-sysroot during bootstrap
On 07/04/13 09:40, Jack Howarth wrote: Currently I am forced to manually patch fixincludes/fixinc.in to have the DIR passed to --with-sysroot honored during the bootstrap. Thanks in advance for any help in getting this oversight in fixincludes fixed for gcc 4.9. Jack I saw the bug report. I find autotools sufficiently flexible that they are neigh on opaque. I *think* you'll need: AC_ARG_WITH([sysroot], [the system include directory -- default: /usr/include], [ AC_DEFINE_UNQUOTED([SYSTEM_INC_DIR], "$withval", [system include directory]) [if test -d "$withval" ; then SYSTEM_INC_DIR=$withval else AC_MSG_ERROR([provided value is not a directory: $withval]) ; fi]], [SYSTEM_INC_DIR=/usr/include]) and then replace the INPUTLIST definition with: test $# -eq 0 && INPUTLIST="@SYSTEM_INC_DIR@" || INPUTLIST="$*" using "$@" is confusing and won't actually work: $ set a b c\ d;echo $#;f="$@";set -- $f; echo $# 3 4 Anyway, I *think* that works, but like I said, it's pretty opaque to me.
Re: PR57792 fixincludes doesn't honor the use of --with-sysroot during bootstrap
On Thu, Jul 04, 2013 at 10:41:45AM -0700, Bruce Korb wrote:
> On 07/04/13 09:40, Jack Howarth wrote:
>> Currently I am forced to manually patch fixincludes/fixinc.in to have the
>> DIR passed to
>> --with-sysroot honored during the bootstrap. Thanks in advance for any help
>> in getting
>> this oversight in fixincludes fixed for gcc 4.9.
>> Jack
>
> I saw the bug report. I find autotools sufficiently flexible that they
> are neigh on opaque. I *think* you'll need:
>
> AC_ARG_WITH([sysroot],
> [the system include directory -- default: /usr/include],
> [ AC_DEFINE_UNQUOTED([SYSTEM_INC_DIR], "$withval",
> [system include directory])
>
> [if test -d "$withval" ; then SYSTEM_INC_DIR=$withval
>else AC_MSG_ERROR([provided value is not a directory: $withval]) ;
> fi]],
>
> [SYSTEM_INC_DIR=/usr/include])
Unfortunately there seems to be a syntax error related to the use of
AC_MSG_ERROR. Both
your original change and the variation attached produce an error when I run
autoreconf in
fixincludes...
% autoreconf -iv
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal
autoreconf: configure.ac: tracing
autoreconf: configure.ac: not using Libtool
autoreconf: running: /sw/bin/autoconf-2.64
configure.ac:34: error: possibly undefined macro: AC_MSG_ERROR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf: /sw/bin/autoconf-2.64 failed with exit status: 1
>
> and then replace the INPUTLIST definition with:
>
> test $# -eq 0 && INPUTLIST="@SYSTEM_INC_DIR@" || INPUTLIST="$*"
>
> using "$@" is confusing and won't actually work:
>
>> $ set a b c\ d;echo $#;f="$@";set -- $f; echo $#
>> 3
>> 4
>
>
> Anyway, I *think* that works, but like I said, it's pretty opaque to me.
Index: fixincludes/configure.ac
===
--- fixincludes/configure.ac(revision 200679)
+++ fixincludes/configure.ac(working copy)
@@ -24,6 +24,18 @@
# Determine the noncanonical target name, for directory use.
ACX_NONCANONICAL_TARGET
+# Honor --with-sysroot
+AC_ARG_WITH([sysroot],
+ [the system include directory -- default: /usr/include],
+ [AC_DEFINE_UNQUOTED([SYSTEM_INC_DIR], "$withval",
+ [system include directory])
+ [if test -d "$withval" ; then
+SYSTEM_INC_DIR=$withval
+ else
+AC_MSG_ERROR([provided value is not a directory: $withval]);
+ fi]],
+ [SYSTEM_INC_DIR=/usr/include])
+
# Specify the local prefix
local_prefix=
AC_ARG_WITH(local-prefix,
Index: fixincludes/fixinc.in
===
--- fixincludes/fixinc.in (revision 200679)
+++ fixincludes/fixinc.in (working copy)
@@ -173,9 +173,9 @@
#
if test $# -eq 0
then
-INPUTLIST="/usr/include"
+INPUTLIST="@SYSTEM_INC_DIR@"
else
-INPUTLIST="$@"
+INPUTLIST="$*"
fi
for INPUT in ${INPUTLIST} ; do
+
Здравствуйте! Меня зовут Bячеслaв. Наш сервис занимается распространением коммерческих предложений в сети. Предлагаем сформировать базу данных предприятий по нужным критериям и сделать рассылку по данной базе. Цена данной услуги - совсем невысокая.В случае заинтересованности - я предоставлю прайс-лист по всем базам Если это возможно - сообщите пожалуйста Ваш Ваш телефон или skype - я объясню о данном виде рекламы более подробно. С уважением Bячеслaв.
Re: Some questions about contributing to GCC
On 4 July 2013 20:19, wrote: > > We want to contribute to GCC, but we are confused about the preferred work > flow in GCC community. Should we report the bug along with the suggested > patch at the same time? Or, after bug reporting we send the suggested > patch to gcc-patch@ and so on? Would a bug report be rejected because no > patch is present? Dear Chang, I added the GCC list in CC in case others want to add something to my reply. Valid bug reports are not rejected because there is no patch. We could close a lot of bugs if we started doing that! But it wouldn't be a nice thing to do... Patches already tested should go to gcc-patches always. Bug reports sometimes contain patches because they are untested or incomplete, but they are posted to gcc-patches even if they don't require a review. If you propose a non-trivial patch, then GCC requires some legal papers to accept your code. See: http://gcc.gnu.org/contribute.html Trivial patches can go without copyright disclaimer/assignment, but you still need to test them and format them appropriately. Getting this wrong the first time is normal, so reviewers may ask you to do some formatting changes before accepting the patch. If you have more questions, please feel free to ask. Reading what people are doing in gcc-patches is also a good way to learn the right work-flow. Cheers, Manuel. > Thanks > -Chang > >
GNU Tools Cauldron 2013 - last minute details
An update on this year's Cauldron. As I mentioned before, we have reached the maximum number of attendees that we can accept. Registrations are now closed. If you had registered but will no longer be able to attend, please let us know so we can free up that slot for someone else. I have added a local information section to http://gcc.gnu.org/wiki/cauldron2013. It contains last minute details on the conference location, transportation, etc. I have also updated the schedule and presentations to reflect recent changes. Please continue checking the web site for last minute changes. If you are presenting and you don't see your presentation or it is in an inconvenient time slot, please let us know. Diego.
Re: PR57792 fixincludes doesn't honor the use of --with-sysroot during bootstrap
On Thu, Jul 04, 2013 at 10:41:45AM -0700, Bruce Korb wrote:
> On 07/04/13 09:40, Jack Howarth wrote:
>> Currently I am forced to manually patch fixincludes/fixinc.in to have the
>> DIR passed to
>> --with-sysroot honored during the bootstrap. Thanks in advance for any help
>> in getting
>> this oversight in fixincludes fixed for gcc 4.9.
>> Jack
>
> I saw the bug report. I find autotools sufficiently flexible that they
> are neigh on opaque. I *think* you'll need:
>
> AC_ARG_WITH([sysroot],
> [the system include directory -- default: /usr/include],
> [ AC_DEFINE_UNQUOTED([SYSTEM_INC_DIR], "$withval",
> [system include directory])
>
> [if test -d "$withval" ; then SYSTEM_INC_DIR=$withval
>else AC_MSG_ERROR([provided value is not a directory: $withval]) ;
> fi]],
>
> [SYSTEM_INC_DIR=/usr/include])
>
> and then replace the INPUTLIST definition with:
>
> test $# -eq 0 && INPUTLIST="@SYSTEM_INC_DIR@" || INPUTLIST="$*"
>
> using "$@" is confusing and won't actually work:
>
>> $ set a b c\ d;echo $#;f="$@";set -- $f; echo $#
>> 3
>> 4
>
>
> Anyway, I *think* that works, but like I said, it's pretty opaque to me.
It appears that the existing code is sufficient. I'm not sure how I missed
this in my previous
testing but a build with...
../gcc-4.8.1/configure --prefix=/sw --prefix=/sw/lib/gcc4.8
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.8/info
--enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw
--with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --enable-checking=release --x-includes=/usr/X11R6/include
--x-libraries=/usr/X11R6/lib --program-suffix=-fsf-4.8
--with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk
...produced...
chmod a+rx include-fixed
if [ -d ../prev-gcc ]; then \
cd ../prev-gcc && \
/Library/Developer/CommandLineTools/usr/bin/make
real-install-headers-tar DESTDIR=`pwd`/../gcc/ \
libsubdir=. ; \
else \
set -e; for ml in `cat fixinc_list`; do \
sysroot_headers_suffix=`echo ${ml} | sed -e 's/;.*$//'`; \
multi_dir=`echo ${ml} | sed -e 's/^[^;]*;//'`; \
fix_dir=include-fixed${multi_dir}; \
if ! false && test ! -d `echo
/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk${sysroot_headers_suffix}/usr/include
| sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`; then \
echo The directory that should contain system headers does not
exist: >&2 ; \
echo " `echo
/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk${sysroot_headers_suffix}/usr/include
| sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`" >&2 ; \
tooldir_sysinc=`echo
"/sw/lib/gcc4.8/lib/gcc/x86_64-apple-darwin13.0.0/4.8.1/../../../../x86_64-apple-darwin13.0.0/sys-include"
| sed -e :a -e "s,[^/]*/\.\.\/,," -e ta`; \
if test "x`echo
/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk${sysroot_headers_suffix}/usr/include
| sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`" = "x${tooldir_sysinc}"; \
then sleep 1; else exit 1; fi; \
fi; \
/bin/sh ../../gcc-4.8.1/gcc/../mkinstalldirs ${fix_dir}; \
chmod a+rx ${fix_dir} || true; \
(TARGET_MACHINE='x86_64-apple-darwin13.0.0'; srcdir=`cd
../../gcc-4.8.1/gcc; ${PWDCMD-pwd}`; \
SHELL='/bin/sh'; MACRO_LIST=`${PWDCMD-pwd}`/macro_list ; \
gcc_dir=`${PWDCMD-pwd}` ; \
export TARGET_MACHINE srcdir SHELL MACRO_LIST && \
cd ../build-x86_64-apple-darwin13.0.0/fixincludes && \
/bin/sh ./fixinc.sh "${gcc_dir}/${fix_dir}" \
`echo
/Library/Developer/CommandLineTools/SDKs/MacOSX10.9.sdk${sysroot_headers_suffix}/usr/include
| sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta` ); \
rm -f ${fix_dir}/syslimits.h; \
if [ -f ${fix_dir}/limits.h ]; then \
mv ${fix_dir}/limits.h ${fix_dir}/syslimits.h; \
else \
cp ../../gcc-4.8.1/gcc/gsyslimits.h ${fix_dir}/syslimits.h; \
fi; \
chmod a+r ${fix_dir}/syslimits.h; \
done; \
fi
(cd `${PWDCMD-pwd}`/include-fixed ; \
tar -cf - .; exit 0) | (cd
/sw/src/fink.build/gcc48-4.8.1-1001/darwin_objdir/prev-gcc/../gcc/./include-fixed;
tar xpf - )
echo timestamp > stmp-fixinc
if [ -d include ] ; then true; else mkdir include; chmod a+rx include; fi
if [ -d include-fixed ] ; then true; else mkdir include-fixed; chmod a+rx
include-fixed; fi
Sorry for the noise as I was certain that I had tested just --with-sysroot
before. The top level configure really needs adjusted
to make '--with-sysroot="`xcrun --show-sdk-path`"' the default behavior on
darwin13 and later.
Jack
Re: PR57792 fixincludes doesn't honor the use of --with-sysroot during bootstrap
Does anyone know if it is possible to have the toplevel configure.ac set... --with-sysroot="`xcrun --show-sdk-path`" for darwin13 or later? In particular, I am confused by the fact that the toplevel configure.ac doesn't define that particular configure option and just passes it down to the lower level configure files. It is unclear how you are supposed to set such a configure option in the toplevel configure file where is not defined. Any advice would be welcome. Jack
Regression: 4.8.0 and above
http://gcc.gnu.org/bugzilla//show_bug.cgi?id=56779
Can someone please take a look at this bug? Since 4.8.0 we have
this annoying error when g++ complains about libintl:
configure:3223: checking whether the C++ compiler (c++ -march=native
-O3 -pipe -floop-interchange -floop-strip-mine -floop-block
-L/usr/local/ssl/lib -L/usr/local/BerkeleyDB/lib -L/usr/X11/lib
-L/usr/local/lib64) works
configure:3239: c++ -o conftest -march=native -O3 -pipe
-floop-interchange -floop-strip-mine -floop-block -L/usr/local/ssl/lib
-L/usr/local/BerkeleyDB/lib -L/usr/X11/lib -L/usr/local/lib64 conftest.C 1>&5
/usr/local/lib64/libstdc++.so: undefined reference to `libintl_gettext'
/usr/local/lib64/libstdc++.so: undefined reference to
`libintl_textdomain'
/usr/local/lib64/libstdc++.so: undefined reference to
`libintl_bindtextdomain'
collect2: error: ld returned 1 exit status
configure: failed program was:
#line 3234 "configure"
#include "confdefs.h"
int main(){return(0);}
**
I tested with 4.8.2 20130620 (prerelease) and it still happens.
Any hints? Thanks.
--
Linux 3.10.0: Unicycling Gorilla
http://www.youtube.com/DanielFragaBR
http://www.libertarios.org.br
