Patchwork [lto-plugin] : Don't use sys/wait.h for mingw targets

login
register
mail settings
Submitter Kai Tietz
Date Dec. 2, 2010, 1:11 p.m.
Message ID <AANLkTikfLoO-KyaiHEXrFU25QEk9C0WDeUSY20z1BcoV@mail.gmail.com>
Download mbox | patch
Permalink /patch/73962/
State New
Headers show

Comments

Kai Tietz - Dec. 2, 2010, 1:11 p.m.
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
Kai Tietz - Dec. 3, 2010, noon
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
Richard Henderson - Dec. 3, 2010, 10:54 p.m.
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~
alsp - Dec. 6, 2010, 2:26 p.m.
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
Kai Tietz - Dec. 6, 2010, 2:43 p.m.
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
alsp - Dec. 6, 2010, 3:22 p.m.
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
>

Patch

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);