| Message ID | AANLkTikfLoO-KyaiHEXrFU25QEk9C0WDeUSY20z1BcoV@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
2010/12/2 Kai Tietz <ktietz70@googlemail.com>: > 2010/12/2 Kai Tietz <ktietz70@googlemail.com>: >> 2010/12/2 alsp <alansparkstar@gmail.com>: >>> >>>>>>> Tested for x86_64-w64-mingw32, i686-pc-mingw32, and i686-pc-cygwin. Ok >>>>>>> for apply? >>> >>> Hi, >>> >>> I've been trying to compile GCC on MinGW for the past few days and was stuck >>> on the wait.h problem until I luckily came across this post. It has resolved >>> that particular issue but now I'm getting a different error: >>> >>> /bin/sh ./libtool --tag=CC --mode=compile mingw32-gcc -DHAVE_CONFIG_H -I. >>> -I.. >>> /../src/lto-plugin -I../../src/lto-plugin/../include -DHAVE_CONFIG_H -Wall >>> -We >>> rror -g -O2 -D__USE_MINGW_ACCESS -c -o lto-plugin.lo >>> ../../src/lto-plugin/lto-pl >>> ugin.c >>> libtool: compile: mingw32-gcc -DHAVE_CONFIG_H -I. -I../../src/lto-plugin >>> -I../. >>> ./src/lto-plugin/../include -DHAVE_CONFIG_H -Wall -Werror -g -O2 >>> -D__USE_MINGW_A >>> CCESS -c ../../src/lto-plugin/lto-plugin.c -o lto-plugin.o >>> cc1.exe: warnings being treated as errors >>> ../../src/lto-plugin/lto-plugin.c: In function 'exec_lto_wrapper': >>> ../../src/lto-plugin/lto-plugin.c:556:3: error: implicit declaration of >>> function >>> 'WIFEXITED' >>> ../../src/lto-plugin/lto-plugin.c:556:3: error: implicit declaration of >>> function >>> 'WEXITSTATUS' >>> make[2]: *** [lto-plugin.lo] Error 1 >>> >>> I've installed MSYS, MinGW, Binutils, Flex, Bison, GMP, MPFR, MPC and am >>> running Windows 7 32-bit. >>> >>> Not sure what other details may be useful - let me know if there are any >>> other details that I can provide. >>> >>> Thanks, >>> Alan >> >> Alan, >> >> sorry for that. I have the following defines in my local headers >> (which aren't standard) and I will prepare a patch for lto-plugin.c >> for this. >> If you define '#define WEXITSTATUS(w) (((w) >> 8) & 0xff)' and >> '#define WIFEXITED(w) (((w) & 0xff) == 0)', the build will be >> then successful. >> >> For win32 the result of status can be SIGABRT in the lower 8-bits (if >> child got a signal), or in the upper 8 bit the exit-code. >> >> Regards, >> Kai >> > > Please could you verify that the following patch works for you? (I > have at the moment no environment up for building a native compiler > for mingw). > > ChangeLog > > 2010-12-02 Kai Tietz > > * lto-plugin.c (exec_lto_wrapper): Special case check without > sys/wait.h header. > > > Ok for apply, if test is successful? > > Regards, > Kai > > Index: lto-plugin.c > =================================================================== > --- lto-plugin.c (revision 167365) > +++ lto-plugin.c (working copy) > @@ -553,9 +553,12 @@ > > t = pex_get_status (pex, 1, &status); > check (t == 1, LDPL_FATAL, "could not get lto-wrapper exit status"); > +#ifdef HAVE_SYS_WAIT_H > check (WIFEXITED (status) && WEXITSTATUS (status) == 0, LDPL_FATAL, > "lto-wrapper failed"); > - > +#else > + check (!status, LDPL_FATAL, "lto-wrapper failed"); > +#endif > pex_free (pex); > > free (at_args); > I tested patch for native build of i686-pc-mingw32 (without my private header extensions). Ok for apply? Kai
On 12/02/2010 05:11 AM, Kai Tietz wrote: > +#ifdef HAVE_SYS_WAIT_H > check (WIFEXITED (status) && WEXITSTATUS (status) == 0, LDPL_FATAL, > "lto-wrapper failed"); > - > +#else > + check (!status, LDPL_FATAL, "lto-wrapper failed"); > +#endif You should be using AC_HEADER_SYS_WAIT instead of a direct check against the header. That will define WIFEXITED for you if needed. C.f. libiberty/configure.ac. r~
Kai Tietz-2 wrote: > > 2010/12/2 Kai Tietz <ktietz70@googlemail.com>: >> 2010/12/2 alsp <alansparkstar@gmail.com>: >>> >>>>>>> Tested for x86_64-w64-mingw32, i686-pc-mingw32, and i686-pc-cygwin. >>>>>>> Ok >>>>>>> for apply? >>> >>> Hi, >>> >>> I've been trying to compile GCC on MinGW for the past few days and was >>> stuck >>> on the wait.h problem until I luckily came across this post. It has >>> resolved >>> that particular issue but now I'm getting a different error: >>> >>> /bin/sh ./libtool --tag=CC --mode=compile mingw32-gcc -DHAVE_CONFIG_H >>> -I. >>> -I.. >>> /../src/lto-plugin -I../../src/lto-plugin/../include -DHAVE_CONFIG_H >>> -Wall >>> -We >>> rror -g -O2 -D__USE_MINGW_ACCESS -c -o lto-plugin.lo >>> ../../src/lto-plugin/lto-pl >>> ugin.c >>> libtool: compile: mingw32-gcc -DHAVE_CONFIG_H -I. >>> -I../../src/lto-plugin >>> -I../. >>> ./src/lto-plugin/../include -DHAVE_CONFIG_H -Wall -Werror -g -O2 >>> -D__USE_MINGW_A >>> CCESS -c ../../src/lto-plugin/lto-plugin.c -o lto-plugin.o >>> cc1.exe: warnings being treated as errors >>> ../../src/lto-plugin/lto-plugin.c: In function 'exec_lto_wrapper': >>> ../../src/lto-plugin/lto-plugin.c:556:3: error: implicit declaration of >>> function >>> 'WIFEXITED' >>> ../../src/lto-plugin/lto-plugin.c:556:3: error: implicit declaration of >>> function >>> 'WEXITSTATUS' >>> make[2]: *** [lto-plugin.lo] Error 1 >>> >>> I've installed MSYS, MinGW, Binutils, Flex, Bison, GMP, MPFR, MPC and am >>> running Windows 7 32-bit. >>> >>> Not sure what other details may be useful - let me know if there are any >>> other details that I can provide. >>> >>> Thanks, >>> Alan >> >> Alan, >> >> sorry for that. I have the following defines in my local headers >> (which aren't standard) and I will prepare a patch for lto-plugin.c >> for this. >> If you define '#define WEXITSTATUS(w) (((w) >> 8) & 0xff)' and >> '#define WIFEXITED(w) (((w) & 0xff) == 0)', the build will be >> then successful. >> >> For win32 the result of status can be SIGABRT in the lower 8-bits (if >> child got a signal), or in the upper 8 bit the exit-code. >> >> Regards, >> Kai >> > > Please could you verify that the following patch works for you? (I > have at the moment no environment up for building a native compiler > for mingw). > > ChangeLog > > 2010-12-02 Kai Tietz > > * lto-plugin.c (exec_lto_wrapper): Special case check without > sys/wait.h header. > > > Ok for apply, if test is successful? > > Hi Kai, Thanks for your help and sorry for the delay in responding. I've been away from the office. I have tested your patch and I think it has resolved that particular problem but I'm not totally sure because I'm getting a different error now. I'm now getting quite a few errors relating to libstdc++-v3 and a lot of them seem to be stemming from shared_ptr_base.h. E.g. "shared_ptr_base.h: In function 'bool std::operator==(const std::__shared_ptr<_Tp, _Lp>&, std::nullptr_t)':" and then many more similar errors. There were too many errors to summarize here, so I've attached a file with all of the output I got from running make: http://old.nabble.com/file/p30366717/ErrorOutput.txt ErrorOutput.txt What I'm not sure about is whether this is related to the previous problem or if I'm missing another dependency. As I mentioned before, my setup is MinGW + MSYS, Flex, Bison, GMP, MPFR, MPC. Does this sound OK? Thanks, Alan
2010/12/6 alsp <alansparkstar@gmail.com>: > > > Kai Tietz-2 wrote: >> >> 2010/12/2 Kai Tietz <ktietz70@googlemail.com>: >>> 2010/12/2 alsp <alansparkstar@gmail.com>: >>>> >>>>>>>> Tested for x86_64-w64-mingw32, i686-pc-mingw32, and i686-pc-cygwin. >>>>>>>> Ok >>>>>>>> for apply? >>>> >>>> Hi, >>>> >>>> I've been trying to compile GCC on MinGW for the past few days and was >>>> stuck >>>> on the wait.h problem until I luckily came across this post. It has >>>> resolved >>>> that particular issue but now I'm getting a different error: >>>> >>>> /bin/sh ./libtool --tag=CC --mode=compile mingw32-gcc -DHAVE_CONFIG_H >>>> -I. >>>> -I.. >>>> /../src/lto-plugin -I../../src/lto-plugin/../include -DHAVE_CONFIG_H >>>> -Wall >>>> -We >>>> rror -g -O2 -D__USE_MINGW_ACCESS -c -o lto-plugin.lo >>>> ../../src/lto-plugin/lto-pl >>>> ugin.c >>>> libtool: compile: mingw32-gcc -DHAVE_CONFIG_H -I. >>>> -I../../src/lto-plugin >>>> -I../. >>>> ./src/lto-plugin/../include -DHAVE_CONFIG_H -Wall -Werror -g -O2 >>>> -D__USE_MINGW_A >>>> CCESS -c ../../src/lto-plugin/lto-plugin.c -o lto-plugin.o >>>> cc1.exe: warnings being treated as errors >>>> ../../src/lto-plugin/lto-plugin.c: In function 'exec_lto_wrapper': >>>> ../../src/lto-plugin/lto-plugin.c:556:3: error: implicit declaration of >>>> function >>>> 'WIFEXITED' >>>> ../../src/lto-plugin/lto-plugin.c:556:3: error: implicit declaration of >>>> function >>>> 'WEXITSTATUS' >>>> make[2]: *** [lto-plugin.lo] Error 1 >>>> >>>> I've installed MSYS, MinGW, Binutils, Flex, Bison, GMP, MPFR, MPC and am >>>> running Windows 7 32-bit. >>>> >>>> Not sure what other details may be useful - let me know if there are any >>>> other details that I can provide. >>>> >>>> Thanks, >>>> Alan >>> >>> Alan, >>> >>> sorry for that. I have the following defines in my local headers >>> (which aren't standard) and I will prepare a patch for lto-plugin.c >>> for this. >>> If you define '#define WEXITSTATUS(w) (((w) >> 8) & 0xff)' and >>> '#define WIFEXITED(w) (((w) & 0xff) == 0)', the build will be >>> then successful. >>> >>> For win32 the result of status can be SIGABRT in the lower 8-bits (if >>> child got a signal), or in the upper 8 bit the exit-code. >>> >>> Regards, >>> Kai >>> >> >> Please could you verify that the following patch works for you? (I >> have at the moment no environment up for building a native compiler >> for mingw). >> >> ChangeLog >> >> 2010-12-02 Kai Tietz >> >> * lto-plugin.c (exec_lto_wrapper): Special case check without >> sys/wait.h header. >> >> >> Ok for apply, if test is successful? >> >> > > Hi Kai, > > Thanks for your help and sorry for the delay in responding. I've been away > from the office. > > I have tested your patch and I think it has resolved that particular problem > but I'm not totally sure because I'm getting a different error now. I'm now > getting quite a few errors relating to libstdc++-v3 and a lot of them seem > to be stemming from shared_ptr_base.h. E.g. "shared_ptr_base.h: In function > 'bool std::operator==(const std::__shared_ptr<_Tp, _Lp>&, std::nullptr_t)':" > and then many more similar errors. > > There were too many errors to summarize here, so I've attached a file with > all of the output I got from running make: > http://old.nabble.com/file/p30366717/ErrorOutput.txt ErrorOutput.txt > > What I'm not sure about is whether this is related to the previous problem > or if I'm missing another dependency. As I mentioned before, my setup is > MinGW + MSYS, Flex, Bison, GMP, MPFR, MPC. Does this sound OK? > > Thanks, > Alan I will take a look. But your new report looks not related to the lto-plugin any more (at least the plugin seems to work as shown by my tests). Issue about libstdc++ in combination with lto could be caused by missing dllexport marking of exported libstdc++ functions in shared version. Additionally there is a fix about library re-passing open AFAIR. Kai
Hi All, See my message below. I didn't send it in plain-text and it bounced. Alan On Mon, Dec 6, 2010 at 3:18 PM, Alan Spark <alansparkstar@gmail.com> wrote: > > Hi Kai, > > Thanks for the speedy response. > This is my first attempt at compiling GCC and I had also suspected that it may be unrelated to lto-plugin after my experiences over the past week. I'll continue to work my way through it also. Any further ideas from anyone would be greatly appreciated. > Thanks, > Alan > On Mon, Dec 6, 2010 at 2:43 PM, Kai Tietz <ktietz70@googlemail.com> wrote: >> >> 2010/12/6 alsp <alansparkstar@gmail.com>: >> > >> > >> > Kai Tietz-2 wrote: >> >> >> >> 2010/12/2 Kai Tietz <ktietz70@googlemail.com>: >> >>> 2010/12/2 alsp <alansparkstar@gmail.com>: >> >>>> >> >>>>>>>> Tested for x86_64-w64-mingw32, i686-pc-mingw32, and i686-pc-cygwin. >> >>>>>>>> Ok >> >>>>>>>> for apply? >> >>>> >> >>>> Hi, >> >>>> >> >>>> I've been trying to compile GCC on MinGW for the past few days and was >> >>>> stuck >> >>>> on the wait.h problem until I luckily came across this post. It has >> >>>> resolved >> >>>> that particular issue but now I'm getting a different error: >> >>>> >> >>>> /bin/sh ./libtool --tag=CC --mode=compile mingw32-gcc -DHAVE_CONFIG_H >> >>>> -I. >> >>>> -I.. >> >>>> /../src/lto-plugin -I../../src/lto-plugin/../include -DHAVE_CONFIG_H >> >>>> -Wall >> >>>> -We >> >>>> rror -g -O2 -D__USE_MINGW_ACCESS -c -o lto-plugin.lo >> >>>> ../../src/lto-plugin/lto-pl >> >>>> ugin.c >> >>>> libtool: compile: mingw32-gcc -DHAVE_CONFIG_H -I. >> >>>> -I../../src/lto-plugin >> >>>> -I../. >> >>>> ./src/lto-plugin/../include -DHAVE_CONFIG_H -Wall -Werror -g -O2 >> >>>> -D__USE_MINGW_A >> >>>> CCESS -c ../../src/lto-plugin/lto-plugin.c -o lto-plugin.o >> >>>> cc1.exe: warnings being treated as errors >> >>>> ../../src/lto-plugin/lto-plugin.c: In function 'exec_lto_wrapper': >> >>>> ../../src/lto-plugin/lto-plugin.c:556:3: error: implicit declaration of >> >>>> function >> >>>> 'WIFEXITED' >> >>>> ../../src/lto-plugin/lto-plugin.c:556:3: error: implicit declaration of >> >>>> function >> >>>> 'WEXITSTATUS' >> >>>> make[2]: *** [lto-plugin.lo] Error 1 >> >>>> >> >>>> I've installed MSYS, MinGW, Binutils, Flex, Bison, GMP, MPFR, MPC and am >> >>>> running Windows 7 32-bit. >> >>>> >> >>>> Not sure what other details may be useful - let me know if there are any >> >>>> other details that I can provide. >> >>>> >> >>>> Thanks, >> >>>> Alan >> >>> >> >>> Alan, >> >>> >> >>> sorry for that. I have the following defines in my local headers >> >>> (which aren't standard) and I will prepare a patch for lto-plugin.c >> >>> for this. >> >>> If you define '#define WEXITSTATUS(w) (((w) >> 8) & 0xff)' and >> >>> '#define WIFEXITED(w) (((w) & 0xff) == 0)', the build will be >> >>> then successful. >> >>> >> >>> For win32 the result of status can be SIGABRT in the lower 8-bits (if >> >>> child got a signal), or in the upper 8 bit the exit-code. >> >>> >> >>> Regards, >> >>> Kai >> >>> >> >> >> >> Please could you verify that the following patch works for you? (I >> >> have at the moment no environment up for building a native compiler >> >> for mingw). >> >> >> >> ChangeLog >> >> >> >> 2010-12-02 Kai Tietz >> >> >> >> * lto-plugin.c (exec_lto_wrapper): Special case check without >> >> sys/wait.h header. >> >> >> >> >> >> Ok for apply, if test is successful? >> >> >> >> >> > >> > Hi Kai, >> > >> > Thanks for your help and sorry for the delay in responding. I've been away >> > from the office. >> > >> > I have tested your patch and I think it has resolved that particular problem >> > but I'm not totally sure because I'm getting a different error now. I'm now >> > getting quite a few errors relating to libstdc++-v3 and a lot of them seem >> > to be stemming from shared_ptr_base.h. E.g. "shared_ptr_base.h: In function >> > 'bool std::operator==(const std::__shared_ptr<_Tp, _Lp>&, std::nullptr_t)':" >> > and then many more similar errors. >> > >> > There were too many errors to summarize here, so I've attached a file with >> > all of the output I got from running make: >> > http://old.nabble.com/file/p30366717/ErrorOutput.txt ErrorOutput.txt >> > >> > What I'm not sure about is whether this is related to the previous problem >> > or if I'm missing another dependency. As I mentioned before, my setup is >> > MinGW + MSYS, Flex, Bison, GMP, MPFR, MPC. Does this sound OK? >> > >> > Thanks, >> > Alan >> >> I will take a look. But your new report looks not related to the >> lto-plugin any more (at least the plugin seems to work as shown by my >> tests). Issue about libstdc++ in combination with lto could be caused >> by missing dllexport marking of exported libstdc++ functions in shared >> version. Additionally there is a fix about library re-passing open >> AFAIR. >> >> Kai >> >> >> -- >> | (\_/) This is Bunny. Copy and paste >> | (='.'=) Bunny into your signature to help >> | (")_(") him gain world domination >
Index: lto-plugin.c =================================================================== --- lto-plugin.c (revision 167365) +++ lto-plugin.c (working copy) @@ -553,9 +553,12 @@ t = pex_get_status (pex, 1, &status); check (t == 1, LDPL_FATAL, "could not get lto-wrapper exit status"); +#ifdef HAVE_SYS_WAIT_H check (WIFEXITED (status) && WEXITSTATUS (status) == 0, LDPL_FATAL, "lto-wrapper failed"); - +#else + check (!status, LDPL_FATAL, "lto-wrapper failed"); +#endif pex_free (pex); free (at_args);