Rantings of a crazy dude on GCC_NO_EXECUTABLES

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Rantings of a crazy dude on GCC_NO_EXECUTABLES

Earnie Boyd
GCC_NO_EXECUTABLES is an autoconf macro that got in my way when trying
to build G++-4.7.0 for --target=mingw32 --host=i686-linux-gnu
--build=i686-linux-gnu.  What it actually did was hide an issue in my
target directories and caused libstdc++ to not be able to configure
with it giving an error stating "configure: error: Link tests are not
allowed after GCC_NO_EXECUTABLES".  What I eventually did to find the
real cause was to comment out this macro and execute autoreconf2.64 in
the libstdc++ directory.  Then when configure ran and failed I found
that ${prefix}/{$target}/ld could not find the crt2.o in
${prefix}/{$target}/lib directory.  I had configured and installed
binutils prior to having the mingwrt and w32api libraries so that I
could use the cross linker to build the libraries.  My prefix was
${HOME}/opt and when installed the target binaries were in
${HOME}/opt/mingw32.  I simply went to that directory, renamed lib to
lib-bak, symlinked ../lib lib and then moved lib-bak/ldscripts/ to
lib/.  After this the libstdc++ configure script was fat dumb and
happy to complete even with GCC_NO_EXECUTABLES reinstated.  The issue
is somewhat documented at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107 with no solution but
is closed since it was reported for 4.3.x.  Kai you commented on that
bug, stating something similar to WJFFM but clearly GCC_NO_EXECUTABLES
is hiding the real issue.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Rantings of a crazy dude on GCC_NO_EXECUTABLES

JonY-6
On 8/31/2012 02:57, Earnie Boyd wrote:

> GCC_NO_EXECUTABLES is an autoconf macro that got in my way when trying
> to build G++-4.7.0 for --target=mingw32 --host=i686-linux-gnu
> --build=i686-linux-gnu.  What it actually did was hide an issue in my
> target directories and caused libstdc++ to not be able to configure
> with it giving an error stating "configure: error: Link tests are not
> allowed after GCC_NO_EXECUTABLES".  What I eventually did to find the
> real cause was to comment out this macro and execute autoreconf2.64 in
> the libstdc++ directory.  Then when configure ran and failed I found
> that ${prefix}/{$target}/ld could not find the crt2.o in
> ${prefix}/{$target}/lib directory.  I had configured and installed
> binutils prior to having the mingwrt and w32api libraries so that I
> could use the cross linker to build the libraries.  My prefix was
> ${HOME}/opt and when installed the target binaries were in
> ${HOME}/opt/mingw32.  I simply went to that directory, renamed lib to
> lib-bak, symlinked ../lib lib and then moved lib-bak/ldscripts/ to
> lib/.  After this the libstdc++ configure script was fat dumb and
> happy to complete even with GCC_NO_EXECUTABLES reinstated.  The issue
> is somewhat documented at
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107 with no solution but
> is closed since it was reported for 4.3.x.  Kai you commented on that
> bug, stating something similar to WJFFM but clearly GCC_NO_EXECUTABLES
> is hiding the real issue.
>
As I understand GCC_NO_EXECUTABLES is simply saying it can't continue
because it can't run some of the required tests. Obviously this applies
to cross compiler environments.

libstdc++ is one of the first target support libraries that require a
working xgcc, so it is often the first one to catch a problem with it. A
quick sanity test is to run xgcc with -B/builddir/gcc and try to compile
"int main(){}".

Indeed it is hiding a setup issue, crt?.o missing is just one of the
possible causes. However if your setup is correct, you should not
encounter any issues, yeah WJFFM.



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

signature.asc (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Rantings of a crazy dude on GCC_NO_EXECUTABLES

Earnie Boyd
On Thu, Aug 30, 2012 at 9:56 PM, JonY wrote:

> On 8/31/2012 02:57, Earnie Boyd wrote:
>> GCC_NO_EXECUTABLES is an autoconf macro that got in my way when trying
>> to build G++-4.7.0 for --target=mingw32 --host=i686-linux-gnu
>> --build=i686-linux-gnu.  What it actually did was hide an issue in my
>> target directories and caused libstdc++ to not be able to configure
>> with it giving an error stating "configure: error: Link tests are not
>> allowed after GCC_NO_EXECUTABLES".  What I eventually did to find the
>> real cause was to comment out this macro and execute autoreconf2.64 in
>> the libstdc++ directory.  Then when configure ran and failed I found
>> that ${prefix}/{$target}/ld could not find the crt2.o in
>> ${prefix}/{$target}/lib directory.  I had configured and installed
>> binutils prior to having the mingwrt and w32api libraries so that I
>> could use the cross linker to build the libraries.  My prefix was
>> ${HOME}/opt and when installed the target binaries were in
>> ${HOME}/opt/mingw32.  I simply went to that directory, renamed lib to
>> lib-bak, symlinked ../lib lib and then moved lib-bak/ldscripts/ to
>> lib/.  After this the libstdc++ configure script was fat dumb and
>> happy to complete even with GCC_NO_EXECUTABLES reinstated.  The issue
>> is somewhat documented at
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107 with no solution but
>> is closed since it was reported for 4.3.x.  Kai you commented on that
>> bug, stating something similar to WJFFM but clearly GCC_NO_EXECUTABLES
>> is hiding the real issue.
>>
>
> As I understand GCC_NO_EXECUTABLES is simply saying it can't continue
> because it can't run some of the required tests. Obviously this applies
> to cross compiler environments.
>

GCC_NO_EXECUTABLES checks the ability of the linker to create
executables for the given target and sets a variable "gcc_no_link"
that all other linker tests check and gives the insane message "error:
Link tests are not allowed after GCC_NO_EXECUTABLES" which doesn't
point me to the problem but points to an incorrect use of link tests
in the configure.ac.

> libstdc++ is one of the first target support libraries that require a
> working xgcc, so it is often the first one to catch a problem with it. A
> quick sanity test is to run xgcc with -B/builddir/gcc and try to compile
> "int main(){}".

Actually, libstdc++ has a insane work-around for GCC_NO_EXECUTABLES
when the target is darwin which simply sets GLIBCXX_IS_NATIVE=true and
doesn't execute GCC_NO_EXECUTABLES.  Surely this is an indication that
GCC_NO_EXECUTABLES is the wrong thing for libstdc++ configure.ac to
do.  I know this list is the wrong place to make a change for it but I
wanted the issue to be found by the masses so they can resolve their
issues.

>
> Indeed it is hiding a setup issue, crt?.o missing is just one of the
> possible causes. However if your setup is correct, you should not
> encounter any issues, yeah WJFFM.

WJFFM too now that I have the issue resolved.  GCC_NO_EXECUTABLES hid
the issue I had before it was working.

--
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: Rantings of a crazy dude on GCC_NO_EXECUTABLES

JonY-6
On 8/31/2012 21:06, Earnie Boyd wrote:

> On Thu, Aug 30, 2012 at 9:56 PM, JonY wrote:
>> On 8/31/2012 02:57, Earnie Boyd wrote:
>>> GCC_NO_EXECUTABLES is an autoconf macro that got in my way when trying
>>> to build G++-4.7.0 for --target=mingw32 --host=i686-linux-gnu
>>> --build=i686-linux-gnu.  What it actually did was hide an issue in my
>>> target directories and caused libstdc++ to not be able to configure
>>> with it giving an error stating "configure: error: Link tests are not
>>> allowed after GCC_NO_EXECUTABLES".  What I eventually did to find the
>>> real cause was to comment out this macro and execute autoreconf2.64 in
>>> the libstdc++ directory.  Then when configure ran and failed I found
>>> that ${prefix}/{$target}/ld could not find the crt2.o in
>>> ${prefix}/{$target}/lib directory.  I had configured and installed
>>> binutils prior to having the mingwrt and w32api libraries so that I
>>> could use the cross linker to build the libraries.  My prefix was
>>> ${HOME}/opt and when installed the target binaries were in
>>> ${HOME}/opt/mingw32.  I simply went to that directory, renamed lib to
>>> lib-bak, symlinked ../lib lib and then moved lib-bak/ldscripts/ to
>>> lib/.  After this the libstdc++ configure script was fat dumb and
>>> happy to complete even with GCC_NO_EXECUTABLES reinstated.  The issue
>>> is somewhat documented at
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39107 with no solution but
>>> is closed since it was reported for 4.3.x.  Kai you commented on that
>>> bug, stating something similar to WJFFM but clearly GCC_NO_EXECUTABLES
>>> is hiding the real issue.
>>>
>>
>> As I understand GCC_NO_EXECUTABLES is simply saying it can't continue
>> because it can't run some of the required tests. Obviously this applies
>> to cross compiler environments.
>>
>
> GCC_NO_EXECUTABLES checks the ability of the linker to create
> executables for the given target and sets a variable "gcc_no_link"
> that all other linker tests check and gives the insane message "error:
> Link tests are not allowed after GCC_NO_EXECUTABLES" which doesn't
> point me to the problem but points to an incorrect use of link tests
> in the configure.ac.
>
Basically, it's just that, it can't run anymore tests, a big catch-all
error for such a condition. A prettier error message is always good though.

>> libstdc++ is one of the first target support libraries that require a
>> working xgcc, so it is often the first one to catch a problem with it. A
>> quick sanity test is to run xgcc with -B/builddir/gcc and try to compile
>> "int main(){}".
>
> Actually, libstdc++ has a insane work-around for GCC_NO_EXECUTABLES
> when the target is darwin which simply sets GLIBCXX_IS_NATIVE=true and
> doesn't execute GCC_NO_EXECUTABLES.  Surely this is an indication that
> GCC_NO_EXECUTABLES is the wrong thing for libstdc++ configure.ac to
> do.  I know this list is the wrong place to make a change for it but I
> wanted the issue to be found by the masses so they can resolve their
> issues.
As I understand, GCC never considers Darwin a cross compiler target
since crossing to Darwin is not normally done. So, with Rosetta, it
makes it native enough when crossing from x86_64 Darwin to PPC Darwin in
fat binary style. I think.





------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

signature.asc (203 bytes) Download Attachment