open64-devel Mailing List for Open64 Compiler and Tools
Brought to you by:
ributzka,
suneeljain
Menu
▾
▴
open64-devel — Compiler developers' discussion list.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(19) |
Oct
(49) |
Nov
(61) |
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(16) |
Feb
(13) |
Mar
(12) |
Apr
(36) |
May
(38) |
Jun
(49) |
Jul
(22) |
Aug
(35) |
Sep
(25) |
Oct
(30) |
Nov
(33) |
Dec
(27) |
| 2003 |
Jan
(19) |
Feb
(32) |
Mar
(57) |
Apr
(53) |
May
(37) |
Jun
(55) |
Jul
(38) |
Aug
(21) |
Sep
(8) |
Oct
(18) |
Nov
(31) |
Dec
(22) |
| 2004 |
Jan
(28) |
Feb
(13) |
Mar
(5) |
Apr
(11) |
May
(10) |
Jun
(26) |
Jul
(46) |
Aug
(17) |
Sep
(10) |
Oct
(38) |
Nov
(14) |
Dec
(26) |
| 2005 |
Jan
(14) |
Feb
(1) |
Mar
(18) |
Apr
(8) |
May
(6) |
Jun
|
Jul
|
Aug
(1) |
Sep
(7) |
Oct
(20) |
Nov
(2) |
Dec
(7) |
| 2006 |
Jan
(6) |
Feb
(2) |
Mar
(1) |
Apr
(26) |
May
(2) |
Jun
(3) |
Jul
|
Aug
|
Sep
(7) |
Oct
(3) |
Nov
(1) |
Dec
(11) |
| 2007 |
Jan
(7) |
Feb
|
Mar
(3) |
Apr
(2) |
May
(13) |
Jun
(24) |
Jul
(10) |
Aug
(2) |
Sep
(4) |
Oct
(3) |
Nov
(9) |
Dec
(8) |
| 2008 |
Jan
(15) |
Feb
(2) |
Mar
(5) |
Apr
(9) |
May
(6) |
Jun
(9) |
Jul
(7) |
Aug
(1) |
Sep
(4) |
Oct
(22) |
Nov
|
Dec
(5) |
| 2009 |
Jan
(14) |
Feb
(20) |
Mar
(77) |
Apr
(68) |
May
(33) |
Jun
(34) |
Jul
(88) |
Aug
(56) |
Sep
(64) |
Oct
(51) |
Nov
(155) |
Dec
(102) |
| 2010 |
Jan
(66) |
Feb
(94) |
Mar
(105) |
Apr
(25) |
May
(49) |
Jun
(61) |
Jul
(79) |
Aug
(160) |
Sep
(150) |
Oct
(143) |
Nov
(103) |
Dec
(146) |
| 2011 |
Jan
(104) |
Feb
(137) |
Mar
(143) |
Apr
(215) |
May
(174) |
Jun
(191) |
Jul
(124) |
Aug
(168) |
Sep
(117) |
Oct
(101) |
Nov
(129) |
Dec
(93) |
| 2012 |
Jan
(61) |
Feb
(47) |
Mar
(63) |
Apr
(107) |
May
(38) |
Jun
(28) |
Jul
(72) |
Aug
(81) |
Sep
(8) |
Oct
(10) |
Nov
(9) |
Dec
(4) |
| 2013 |
Jan
(11) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(5) |
Jul
(6) |
Aug
|
Sep
(1) |
Oct
(3) |
Nov
(3) |
Dec
|
| 2014 |
Jan
|
Feb
(2) |
Mar
(4) |
Apr
|
May
|
Jun
(5) |
Jul
(2) |
Aug
(32) |
Sep
|
Oct
(5) |
Nov
(3) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(7) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Jian-Xin L. <la...@gm...> - 2015-03-27 02:35:22
|
The websites and SVN servers are down for maintenance and will be back soon. On Thu, Mar 19, 2015 at 11:43 PM, Yin Ma <yi...@af...> wrote: > Has been with Open64 for so long time. Cannot see open64 die like this. > I can provide web space for hosting or mirroring if needed at least. > > Yin > > > -----Original Message----- > From: cod...@os... [mailto:cod...@os...] > Sent: Thursday, March 19, 2015 7:06 AM > To: Christophe MONAT; ope...@li... > Subject: Re: [Open64-devel] open64.net seems to be down > > The remedy is let it stay down. I don't say this from a "hater" > perspective, but it's time for open64 to die and something else to be > reborn from the ashes. > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Open64-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/open64-devel > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Open64-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/open64-devel > -- Regards, Lai Jian-Xin |
|
From: Yin M. <yi...@af...> - 2015-03-19 16:10:21
|
Has been with Open64 for so long time. Cannot see open64 die like this. I can provide web space for hosting or mirroring if needed at least. Yin -----Original Message----- From: cod...@os... [mailto:cod...@os...] Sent: Thursday, March 19, 2015 7:06 AM To: Christophe MONAT; ope...@li... Subject: Re: [Open64-devel] open64.net seems to be down The remedy is let it stay down. I don't say this from a "hater" perspective, but it's time for open64 to die and something else to be reborn from the ashes. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ Open64-devel mailing list Ope...@li... https://lists.sourceforge.net/lists/listinfo/open64-devel |
|
From: Christophe M. <chr...@st...> - 2015-03-19 15:51:09
|
Kun Ling, On 03/19/15 15:52, Kun Ling wrote: > In case someone want to checkout the code, here is an repository cloned > from Open64 SVN. > > https://github.com/Lingcc/open64 Many thanks for the github pointer. --C |
|
From: <cod...@os...> - 2015-03-19 15:11:11
|
The remedy is let it stay down. I don't say this from a "hater" perspective, but it's time for open64 to die and something else to be reborn from the ashes. |
|
From: Kun L. <lku...@gm...> - 2015-03-19 14:53:02
|
I could not access it either. In case someone want to checkout the code, here is an repository cloned from Open64 SVN. https://github.com/Lingcc/open64 -- Kun Ling On Thu, Mar 19, 2015 at 6:52 AM, Christophe MONAT <chr...@st...> wrote: > The site http://www.open64.net seems to be down - not only for me, > according to various web checkers. > > Can someone reading this list remedy ? > > Thanks, > --C > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Open64-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/open64-devel > -- http://www.lingcc.com |
|
From: Christophe M. <chr...@st...> - 2015-03-19 14:52:22
|
Chris, On 03/19/15 15:06, cod...@os... wrote: > The remedy is let it stay down. I don't say this from a "hater" perspective, but it's time for open64 to die and something else to be reborn from the ashes. Nice to read from you - at not all here is in zombie state :-). Well, sometimes I have to pick a few changes for maintenance, so it make thinks easier to me. --C |
|
From: Christophe M. <chr...@st...> - 2015-03-19 13:52:51
|
The site http://www.open64.net seems to be down - not only for me, according to various web checkers. Can someone reading this list remedy ? Thanks, --C |
|
From: Christophe M. <chr...@st...> - 2014-11-24 16:51:54
|
Hi list, With the attached file and any gcc: $ gcc c29329.c && ./a.out PASSED With the most recent publicly available opencc: $ opencc -v Open64 Compiler Suite: Version 5.0 Built on: 2011-11-09 11:16:36 +0800 Thread model: posix GNU gcc version 4.2.0 (Open64 5.0 driver) $ opencc c29329.c && ./a.out FAILED - there is no need to turn on any optimization to show the issue - the test case is very small and I believe is well-defined with regard to standard conformance - it looks like the offset generated for the access through g_2057 is just wrong - old generation opencc based on gnu3 FR do not exhibit the problem Is someone aware of this issue ? Has anyone a fix for this ? Thanks, -- C STMicroelectronics Christophe MONAT - BP47 12 rue Jules Horowitz FR-38019 Grenoble Cedex Phone: +33 476584252 |
|
From: Jian-Xin L. <la...@gm...> - 2014-11-17 05:19:14
|
I'm not sure if the SL is also using the current scripts/makefiles for configure/make/make install. Maybe someone from SL/ICT can answer this question. Or, do you find if the 'driver' is built successfully? You can copy it to $prefix/usr/bin and rename to opencc. 2014-11-14 16:03 GMT+08:00 黄虎才 <chi...@gm...>: > Hi, all. > I want to port open64 for MIPS, I download the source code of open64.5 and > configure like: > ./configure --prefix=/home/compiler/ --target=sl-unknown-linux-gnu > and then make, make install. > During the making and installation, it works well. But i can't find opencc > in directory > /home/compiler/usr/bin, and if i compile open64 like > ./configure --prefix=/home/compiler/ && make && make install > opencc is located at /home/compiler/bin. > Makefile tells me that x86 is the default target if i don't set --target. > But if i set --target=sl-unknown-linux-gnu for porting, i can't get > compiler open64-for-mips. > Does anybody know why? Thanks a lot. > > > ------------------------------------------------------------------------------ > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > > http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk > _______________________________________________ > Open64-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/open64-devel > > -- Regards, Lai Jian-Xin |
|
From: 黄虎才 <chi...@gm...> - 2014-11-14 08:03:54
|
Hi, all. I want to port open64 for MIPS, I download the source code of open64.5 and configure like: ./configure --prefix=/home/compiler/ --target=sl-unknown-linux-gnu and then make, make install. During the making and installation, it works well. But i can't find opencc in directory /home/compiler/usr/bin, and if i compile open64 like ./configure --prefix=/home/compiler/ && make && make install opencc is located at /home/compiler/bin. Makefile tells me that x86 is the default target if i don't set --target. But if i set --target=sl-unknown-linux-gnu for porting, i can't get compiler open64-for-mips. Does anybody know why? Thanks a lot. |
|
From: Jian-Xin L. <la...@gm...> - 2014-10-16 09:17:07
|
I can only reset the pointer ver, not the ivar_occ to invalid the FSA on
this node.
2014-10-14 10:32 GMT+08:00 Yiran Wang <yir...@gm...>:
> It sounds like no way to update the alias information. In that case, it
> has to be set to NULL.
> For this specific case here, only the FSA information becomes invalid, I
> think, and is there any way to ignore this part only?
>
> Regards,
> Yiran
>
> On Mon, Oct 13, 2014 at 8:11 AM, Jian-Xin Lai <la...@gm...> wrote:
>
>> Hi,
>>
>> I found a wopt epre/sr bug existing in current open64 trunk.
>>
>> Here is a case:
>> p[0] = expr1;
>> while (1) {
>> temp = p[0]; // A
>> stmts (use of temp)
>> if (...)
>> break;
>> p[4] = expr2; // B
>> p += 4; // C
>> }
>>
>> In FSA phase, the points-to for ILOAD in stmt A is set to
>> "Pointer_is_named_symbol" and the Pointer is "p", Pointer_ver is the index
>> of the VSE entry of p. For stmt A and B, they are not aliased because they
>> have the same "pointer" and different offset.
>>
>> After epre/sr, A is eliminated and a new computation is inserted into the
>> end of loop body:
>> temp = expr1;
>> p[0] = temp;
>> while (1) {
>> stmts (use of temp)
>> if (...)
>> break;
>> p[4] = expr2; // B
>> p += 4; // C
>> temp = p[0]; // A'
>> }
>>
>> The IVAR used in A' was created from A. When rehashing the new IVAR, the
>> Ivar_occ is also copied in Rehash_tree_rec in opt_expr.cxx:
>> 196 if (newcr->Ivar_occ() != NULL)
>> 197
>> newcr->Set_ivar_occ(CXX_NEW(OCC_TAB_ENTRY(*newcr->Ivar_occ()),
>> 198 htable->Sym()->Occ_pool()));
>> 199 else
>> 200 newcr->Set_ivar_occ(NULL);
>>
>> Now both A' and A have the same Ivar_occ. Based on the
>> Aliased_Indirect_Rule, the new ILOAD in A' is still not aliased with the
>> ISTORE B. In later CG phase, the scheduler will reorder A' and B.
>>
>> Here is the question, it looks like it's illegal to copy the Ivar_occ
>> from an existing CR to a new CR considering the case of the Ilod/Istr base
>> is changed. But how can we update the Ivar_occ with precise points-to info?
>> The VSE table has been destroyed when WHIRL is converted into CODEMAP.
>>
>>
>> --
>> Regards,
>> Lai Jian-Xin
>>
>>
>> ------------------------------------------------------------------------------
>> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
>> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
>> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
>> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
>> http://p.sf.net/sfu/Zoho
>> _______________________________________________
>> Open64-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/open64-devel
>>
>>
>
--
Regards,
Lai Jian-Xin
|
|
From: Yiran W. <yir...@gm...> - 2014-10-14 02:32:45
|
It sounds like no way to update the alias information. In that case, it has
to be set to NULL.
For this specific case here, only the FSA information becomes invalid, I
think, and is there any way to ignore this part only?
Regards,
Yiran
On Mon, Oct 13, 2014 at 8:11 AM, Jian-Xin Lai <la...@gm...> wrote:
> Hi,
>
> I found a wopt epre/sr bug existing in current open64 trunk.
>
> Here is a case:
> p[0] = expr1;
> while (1) {
> temp = p[0]; // A
> stmts (use of temp)
> if (...)
> break;
> p[4] = expr2; // B
> p += 4; // C
> }
>
> In FSA phase, the points-to for ILOAD in stmt A is set to
> "Pointer_is_named_symbol" and the Pointer is "p", Pointer_ver is the index
> of the VSE entry of p. For stmt A and B, they are not aliased because they
> have the same "pointer" and different offset.
>
> After epre/sr, A is eliminated and a new computation is inserted into the
> end of loop body:
> temp = expr1;
> p[0] = temp;
> while (1) {
> stmts (use of temp)
> if (...)
> break;
> p[4] = expr2; // B
> p += 4; // C
> temp = p[0]; // A'
> }
>
> The IVAR used in A' was created from A. When rehashing the new IVAR, the
> Ivar_occ is also copied in Rehash_tree_rec in opt_expr.cxx:
> 196 if (newcr->Ivar_occ() != NULL)
> 197
> newcr->Set_ivar_occ(CXX_NEW(OCC_TAB_ENTRY(*newcr->Ivar_occ()),
> 198 htable->Sym()->Occ_pool()));
> 199 else
> 200 newcr->Set_ivar_occ(NULL);
>
> Now both A' and A have the same Ivar_occ. Based on the
> Aliased_Indirect_Rule, the new ILOAD in A' is still not aliased with the
> ISTORE B. In later CG phase, the scheduler will reorder A' and B.
>
> Here is the question, it looks like it's illegal to copy the Ivar_occ from
> an existing CR to a new CR considering the case of the Ilod/Istr base is
> changed. But how can we update the Ivar_occ with precise points-to info?
> The VSE table has been destroyed when WHIRL is converted into CODEMAP.
>
>
> --
> Regards,
> Lai Jian-Xin
>
>
> ------------------------------------------------------------------------------
> Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
> Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
> Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Open64-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/open64-devel
>
>
|
|
From: Jian-Xin L. <la...@gm...> - 2014-10-13 15:11:49
|
Hi,
I found a wopt epre/sr bug existing in current open64 trunk.
Here is a case:
p[0] = expr1;
while (1) {
temp = p[0]; // A
stmts (use of temp)
if (...)
break;
p[4] = expr2; // B
p += 4; // C
}
In FSA phase, the points-to for ILOAD in stmt A is set to
"Pointer_is_named_symbol" and the Pointer is "p", Pointer_ver is the index
of the VSE entry of p. For stmt A and B, they are not aliased because they
have the same "pointer" and different offset.
After epre/sr, A is eliminated and a new computation is inserted into the
end of loop body:
temp = expr1;
p[0] = temp;
while (1) {
stmts (use of temp)
if (...)
break;
p[4] = expr2; // B
p += 4; // C
temp = p[0]; // A'
}
The IVAR used in A' was created from A. When rehashing the new IVAR, the
Ivar_occ is also copied in Rehash_tree_rec in opt_expr.cxx:
196 if (newcr->Ivar_occ() != NULL)
197 newcr->Set_ivar_occ(CXX_NEW(OCC_TAB_ENTRY(*newcr->Ivar_occ()),
198 htable->Sym()->Occ_pool()));
199 else
200 newcr->Set_ivar_occ(NULL);
Now both A' and A have the same Ivar_occ. Based on the
Aliased_Indirect_Rule, the new ILOAD in A' is still not aliased with the
ISTORE B. In later CG phase, the scheduler will reorder A' and B.
Here is the question, it looks like it's illegal to copy the Ivar_occ from
an existing CR to a new CR considering the case of the Ilod/Istr base is
changed. But how can we update the Ivar_occ with precise points-to info?
The VSE table has been destroyed when WHIRL is converted into CODEMAP.
--
Regards,
Lai Jian-Xin
|
|
From: Jian-Xin L. <la...@gm...> - 2014-10-08 06:14:36
|
I don't know if someone else is working on this. But if you hit any problem in building/using the library with open64, you can raise them up and get help from this mail list. 2014-10-06 7:51 GMT+08:00 Millad Ghane <mil...@gm...>: > Hello all, > > I was working on a project on Open64. Currently, Open64 uses its library > for OpenMP development. But, there is another library out there that is > developed by Intel. Its targets are mainly GCC, Clang, and obviously ICC. > They do not support Open64. > > I was wondering whether there have been any progress towards this. Is > there any support of Open64 for Intel Runtime library? Is there anyway that > I will be able to build the library and use it with Open64 compiler? > > > > Best Regards, > Millad > > > > ------------------------------------------------------------------------------ > Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer > Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports > Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper > Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer > > http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk > _______________________________________________ > Open64-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/open64-devel > > -- Regards, Lai Jian-Xin |
|
From: Millad G. <mil...@gm...> - 2014-10-05 23:51:46
|
Hello all, I was working on a project on Open64. Currently, Open64 uses its library for OpenMP development. But, there is another library out there that is developed by Intel. Its targets are mainly GCC, Clang, and obviously ICC. They do not support Open64. I was wondering whether there have been any progress towards this. Is there any support of Open64 for Intel Runtime library? Is there anyway that I will be able to build the library and use it with Open64 compiler? Best Regards, Millad |
|
From: Nancy <nan...@gm...> - 2014-08-27 09:07:20
|
Thanks for your Information :)
After give path in front of crt1.o in file "specs", no more issue !!!!
*startfile:
%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:
*/usr/lib/gcc/i386-linux-gnu/*crt1.o%s}}
/usr/lib/gcc/i386-linux-gnu/crti.o%s
%{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}
*nancy@nancy-ThinkPad-T61:~/work/test$ opencc test.c -v*
Open64 Compiler Suite: Version 5.0
Built on: 2014-08-27 15:26:42 +0800
Thread model: posix
GNU gcc version 4.2.0 (Open64 5.0 driver)
/home/nancy/toolchains/open64/open64-gcc-4.2.0/bin/gcc -D__OPEN64__="5.0"
-D__OPENCC__=5 -D__OPENCC_MINOR__=0 -D__OPENCC_PATCHLEVEL__= -O2
-D__OPTIMIZE__ -v -m32 -xc -isystem
/home/nancy/toolchains/open64/include/5.0 -isystem
/home/nancy/toolchains/open64/include -E -msse2 test.c -o /tmp/cci#.h0RJ8o
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../../open64-svn/./osprey-gcc-4.2.0/configure
--prefix=/home/nancy/toolchains/open64/open64-gcc-4.2.0 --with-gnu-as
--with-gnu-ld --enable-languages=c,c++ --disable-bootstrap
--disable-libmudflap --disable-libssp --disable-checking
--enable-threads=posix --enable-tls --with-system-zlib
--enable-__cxa_atexit --srcdir=../../open64-svn/./osprey-gcc-4.2.0
--host=x86_64-redhat-linux --target=x86_64-redhat-linux
Thread model: posix
gcc version 4.2.0
/home/nancy/toolchains/open64/open64-gcc-4.2.0/libexec/gcc/x86_64-redhat-linux/4.2.0/cc1
-E -quiet -v -imultilib 32 -D__OPEN64__="5.0" -D__OPENCC__=5
-D__OPENCC_MINOR__=0 -D__OPENCC_PATCHLEVEL__= -D__OPTIMIZE__ -isystem
/home/nancy/toolchains/open64/include/5.0 -isystem
/home/nancy/toolchains/open64/include test.c -o /tmp/cci#.h0RJ8o -m32
-msse2 -mtune=generic -O2
ignoring nonexistent directory
"/home/nancy/toolchains/open64/open64-gcc-4.2.0/lib/gcc/x86_64-redhat-linux/4.2.0/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/home/nancy/toolchains/open64/include/5.0
/home/nancy/toolchains/open64/include
/usr/local/include
/home/nancy/toolchains/open64/open64-gcc-4.2.0/include
/home/nancy/toolchains/open64/open64-gcc-4.2.0/lib/gcc/x86_64-redhat-linux/4.2.0/include
/usr/include
End of search list.
/home/nancy/toolchains/open64/lib/gcc-lib/x86_64-open64-linux/5.0/cc142 -O2
-fi386-host -fcxx-openmp -msse2 -dx -version -quiet -m32 -fpreprocessed
-fbuiltin -dumpbase test.c /tmp/cci#.h0RJ8o -spinfile /tmp/ccspin#.1M1X2P
GNU C version 4.2.0 (x86_64-redhat-linux)
compiled by GNU C version 4.8.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: fc069a197ccd8d590234e673141ff3f6
/home/nancy/toolchains/open64/lib/gcc-lib/x86_64-open64-linux/5.0/wgen42
-fS,/tmp/ccspin#.1M1X2P -fB,/tmp/ccB#.9dyt6g
Compiling vprintf(0)
Compiling getchar(1)
Compiling fgetc_unlocked(2)
Compiling getc_unlocked(3)
Compiling getchar_unlocked(4)
Compiling putchar(5)
Compiling fputc_unlocked(6)
Compiling putc_unlocked(7)
Compiling putchar_unlocked(8)
Compiling feof_unlocked(9)
Compiling ferror_unlocked(10)
Compiling main(11)
/home/nancy/toolchains/open64/lib/gcc-lib/x86_64-open64-linux/5.0/inline
-LIST:source=off:notes=off -PHASE:w:c -O2 -show -TARG:abi=n32
-LANG:cxx_openmp=on -fB,/tmp/ccB#.9dyt6g -fI,/tmp/ccI#.zfKncI test.c
/home/nancy/toolchains/open64/lib/gcc-lib/x86_64-open64-linux/5.0/be
-LIST:source=off:notes=off -PHASE:w:c -G8 -O2 -show -TARG:abi=n32
-LANG:cxx_openmp=on -LANG:=ansi_c -TARG:processor=core -TARG:sse2=on
-TARG:mmx=on -TARG:sse=on -TARG:sse3=on -TARG:3dnow=off -TARG:sse4a=off
-TARG:ssse3=off -TARG:sse41=off -TARG:sse42=off -TARG:aes=off
-TARG:pclmul=off -TARG:avx=off -TARG:xop=off -TARG:fma=off -TARG:fma4=off
-fB,/tmp/ccI#.zfKncI -s -fs,/tmp/ccspin#.1M1X2P.s test.c
Compiling test.c (/tmp/ccI#.zfKncI) -- Back End
Compiling vprintf(0)
Compiling getchar(1)
Compiling fgetc_unlocked(2)
Compiling getc_unlocked(3)
Compiling getchar_unlocked(4)
Compiling putchar(5)
Compiling fputc_unlocked(6)
Compiling putc_unlocked(7)
Compiling putchar_unlocked(8)
Compiling feof_unlocked(9)
Compiling ferror_unlocked(10)
Compiling main(11)
/home/nancy/toolchains/open64/open64-gcc-4.2.0/bin/gcc -v -m32
/tmp/ccspin#.1M1X2P.s -c -o /tmp/cco.d2fehY
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../../open64-svn/./osprey-gcc-4.2.0/configure
--prefix=/home/nancy/toolchains/open64/open64-gcc-4.2.0 --with-gnu-as
--with-gnu-ld --enable-languages=c,c++ --disable-bootstrap
--disable-libmudflap --disable-libssp --disable-checking
--enable-threads=posix --enable-tls --with-system-zlib
--enable-__cxa_atexit --srcdir=../../open64-svn/./osprey-gcc-4.2.0
--host=x86_64-redhat-linux --target=x86_64-redhat-linux
Thread model: posix
gcc version 4.2.0
as -V -Qy --32 -o /tmp/cco.d2fehY /tmp/ccspin#.1M1X2P.s
GNU汇编版本 2.24 (i686-linux-gnu) 使用BFD版本 (GNU Binutils for Ubuntu) 2.24
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../../open64-svn/./osprey-gcc-4.2.0/configure
--prefix=/home/nancy/toolchains/open64/open64-gcc-4.2.0 --with-gnu-as
--with-gnu-ld --enable-languages=c,c++ --disable-bootstrap
--disable-libmudflap --disable-libssp --disable-checking
--enable-threads=posix --enable-tls --with-system-zlib
--enable-__cxa_atexit --srcdir=../../open64-svn/./osprey-gcc-4.2.0
--host=x86_64-redhat-linux --target=x86_64-redhat-linux
Thread model: posix
gcc version 4.2.0
/home/nancy/toolchains/open64/open64-gcc-4.2.0/libexec/gcc/x86_64-redhat-linux/4.2.0/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 *crt1.o
crti.o */home/nancy/toolchains/open64/open64-gcc-4.2.0/lib/gcc/x86_64-redhat-linux/4.2.0/32/crtbegin.o
-L/home/nancy/toolchains/open64//lib/gcc-lib/x86_64-open64-linux/5.0/32
-L/home/nancy/toolchains/open64/open64-gcc-4.2.0/lib/gcc/x86_64-redhat-linux/4.2.0/32
-L/home/nancy/toolchains/open64/open64-gcc-4.2.0/lib/gcc/x86_64-redhat-linux/4.2.0/../../../../lib/i366-linux-gnu
-L/home/nancy/toolchains/open64/open64-gcc-4.2.0/lib/gcc/x86_64-redhat-linux/4.2.0
-L/home/nancy/toolchains/open64/open64-gcc-4.2.0/lib/gcc/x86_64-redhat-linux/4.2.0/../../..
-rpath
/home/nancy/toolchains/open64//lib/gcc-lib/x86_64-open64-linux/5.0/32
-rpath-link
/home/nancy/toolchains/open64//lib/gcc-lib/x86_64-open64-linux/5.0/32
/tmp/cco.d2fehY -lopen64rt -lgcc --as-needed -lgcc_s --no-as-needed -lc
-lgcc --as-needed -lgcc_s --no-as-needed
/home/nancy/toolchains/open64/open64-gcc-4.2.0/lib/gcc/x86_64-redhat-linux/4.2.0/32/crtend.o
*crtn.o*
/usr/local/bin/ld: error: cannot open crt1.o: 没有那个文件或目录
/usr/local/bin/ld: error: cannot open crti.o: 没有那个文件或目录
/usr/local/bin/ld: error: cannot open crtn.o: 没有那个文件或目录
collect2: ld returned 1 exit status
Open64 uses system original crt1.o, crti.o, and crtn.o but lack of path! I
think this bug needs to be fixed. Also curious why not rebuild them, just
like other multilib(crtend.o......)
I can use GDB to catch its workflow now. Thanks for all your helps! :)
On Wed, Aug 27, 2014 at 1:03 PM, Jian-Xin Lai <la...@gm...> wrote:
> There should be a file named config.log in the libstdc++-v3 and you may
> get more clues fro there. Now the build scripts has built the gcc 4.2 (/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc)
> and tried to use it to build the libstdc++ shipped with gcc 4.2 (otherwise
> there will be compatibility issues between the front end and stdc++).
> Basically, the system libm should be used.
>
>
> 2014-08-26 19:57 GMT+08:00 Nancy <nan...@gm...>:
>
> I don't think so. MULTILIB_OSDIRNAMES controls multilib build, cri.o,
>> crtn.o do not belong to multilib.
>>
>> Here's a walk a round way:
>> Modify the contents of file
>> "build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/specs":
>> *startfile:
>> %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
>> */usr/lib/i386-linux-gnu/*crti.o%s
>> %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}
>>
>> endfile:
>> %{ffast-math|funsafe-math-optimizations:crtfastmath.o%s}
>> %{shared|pie:crtendS.o%s;:crtend.o%s} */usr/lib/gcc/i386-linux-gnu/*
>> crtn.o%s
>>
>> This "specs" file was automatically generated by
>> osprey-gcc-4.2.0/gcc/Makefile.in:1409 rules
>> $(SPECS): xgcc$(exeext)
>> $(GCC_FOR_TARGET) -dumpspecs > tmp-specs
>> mv tmp-specs $(SPECS)
>>
>> I don't known how to control GCC_FOR_TARGET correctly.
>>
>> NEW issue:
>> make[4]:正在离开目录
>> `/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc'
>> Checking multilib configuration for libstdc++-v3...
>> Configuring in x86_64-redhat-linux/libstdc++-v3
>> configure: loading cache ./config.cache
>> *checking build system type... (cached) x86_64-redhat-linux-gnu*
>> *checking host system type... (cached) x86_64-redhat-linux-gnu*
>> *checking target system type... (cached) x86_64-redhat-linux-gnu*
>> *How come to get this result, my machine is i686 smp Ubuntu?*
>>
>> checking for a BSD-compatible install... /usr/bin/install -c
>> checking whether build environment is sane... yes
>> checking for gawk... (cached) gawk
>> checking whether make sets $(MAKE)... (cached) yes
>> checking how to run the C preprocessor... (cached)
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
>> -E
>> checking for egrep... (cached) grep -E
>> checking for x86_64-redhat-linux-gcc... (cached)
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
>> checking for suffix of object files... (cached) o
>> checking whether we are using the GNU C compiler... (cached) yes
>> checking whether
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
>> accepts -g... (cached) yes
>> checking for
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
>> option to accept ANSI C... (cached) none needed
>> checking for x86_64-redhat-linux-g++... (cached)
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> -shared-libgcc
>> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc
>> -nostdinc++
>> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src
>> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src/.libs
>> -m32
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
>> checking whether we are using the GNU C++ compiler... (cached) yes
>> checking whether
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> -shared-libgcc
>> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc
>> -nostdinc++
>> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src
>> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src/.libs
>> -m32
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
>> accepts -g... (cached) yes
>> checking whether ln -s works... yes
>> checking for x86_64-redhat-linux-as... (cached)
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/as
>> checking for x86_64-redhat-linux-ar... (cached) ar
>> checking for x86_64-redhat-linux-ranlib... (cached) ranlib
>> checking whether to enable maintainer-specific portions of Makefiles... no
>> configure: CPU config directory is cpu/i486
>> configure: OS config directory is os/gnu-linux
>> checking for ld used by GCC... (cached)
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld
>> checking if the linker
>> (/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld)
>> is GNU ld... (cached) yes
>> checking for
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld
>> option to reload object files... (cached) -r
>> checking for BSD-compatible nm... (cached)
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/nm
>> checking how to recognise dependant libraries... (cached) pass_all
>> checking the maximum length of command line arguments... (cached) 49153
>> checking for x86_64-redhat-linux-ranlib... (cached) ranlib
>> checking for x86_64-redhat-linux-strip... (cached) strip
>> updating cache ./config.cache
>> loading cache ./config.cache within ltconfig
>> checking whether -lc should be explicitly linked in... (cached) no
>> checking for objdir... .libs
>> checking for
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> option to produce PIC... -fPIC -DPIC
>> checking if
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> PIC flag -fPIC -DPIC works... (cached) yes
>> checking if
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> static flag works... (cached) no
>> finding the maximum length of command line arguments... (cached) 49153
>> checking if
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> supports -c -o file.o... (cached) yes
>> checking if
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> supports -fno-rtti -fno-exceptions ... no
>> checking whether the linker
>> (/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld
>> -m elf_i386) supports shared libraries... yes
>> checking how to hardcode library paths into programs... immediate
>> checking whether stripping libraries is possible... yes
>> checking dynamic linker characteristics... GNU/Linux ld.so
>> checking command to parse
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/nm
>> output... failed
>> checking if libtool supports shared libraries... yes
>> checking whether to build shared libraries... yes
>> checking whether to build static libraries... yes
>> creating libtool
>> updating cache ./config.cache
>> configure: loading cache ./config.cache
>> checking how to run the C++ preprocessor...
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> -shared-libgcc
>> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc
>> -nostdinc++
>> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src
>> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src/.libs
>> -m32
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
>> -E
>> loading cache ./config.cache within ltconfig
>> checking host system type... x86_64-redhat-linux-gnu
>> checking build system type... x86_64-redhat-linux-gnu
>> checking for objdir... .libs
>> checking for
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> option to produce PIC... -fPIC -DPIC
>> checking if
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> PIC flag -fPIC -DPIC works... yes
>> checking if
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> static flag -static works... no
>> finding the maximum length of command line arguments... (cached) 49153
>> checking if
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> supports -c -o file.o... (cached) yes
>> checking if
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>> supports -fno-rtti -fno-exceptions ... yes
>> checking whether the linker
>> (/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld
>> -m elf_i386) supports shared libraries...
>> checking how to hardcode library paths into programs... immediate
>> checking whether stripping libraries is possible... yes
>> checking dynamic linker characteristics... GNU/Linux ld.so
>> checking command to parse
>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/nm
>> output... failed
>> checking if libtool supports shared libraries... yes
>> checking whether to build shared libraries... yes
>> checking whether to build static libraries... yes
>> appending configuration tag "CXX" to libtool
>> checking for exception model to use... call frame
>> checking for compiler with PCH support... yes
>> checking for enabled PCH... yes
>> checking for underlying I/O to use... stdio
>> checking for ANSI C header files... yes
>> checking for sys/types.h... yes
>> checking for sys/stat.h... yes
>> checking for stdlib.h... yes
>> checking for string.h... yes
>> checking for memory.h... yes
>> checking for strings.h... yes
>> checking for inttypes.h... yes
>> checking for stdint.h... yes
>> checking for unistd.h... yes
>> checking for C locale to use... generic
>> checking for std::allocator base class... new
>> configure: "C" header strategy set to c_std
>> checking for enabled long long specializations... yes
>> checking wchar.h usability... yes
>> checking wchar.h presence... yes
>> checking for wchar.h... yes
>> checking for mbstate_t... yes
>> checking wctype.h usability... yes
>> checking wctype.h presence... yes
>> checking for wctype.h... yes
>> checking for enabled wchar_t specializations... yes
>> checking for ISO C99 support in <math.h>... yes
>> checking complex.h usability... yes
>> checking complex.h presence... yes
>> checking for complex.h... yes
>> checking for ISO C99 support in <complex.h>... yes
>> checking for ISO C99 support in <stdio.h>... yes
>> checking for ISO C99 support in <stdlib.h>... yes
>> checking for ISO C99 support in <wchar.h>... yes
>> checking for fully enabled ISO C99 support... yes
>> configure: Debug build flags set to -g3 -O0
>> checking for additional debug build... no
>> checking for extra compiler flags for building...
>> checking for thread model used by GCC... posix
>> checking for atomic builtins... no
>> checking for g++ that supports -ffunction-sections -fdata-sections... yes
>> checking nan.h usability... no
>> checking nan.h presence... no
>> checking for nan.h... no
>> checking ieeefp.h usability... no
>> checking ieeefp.h presence... no
>> checking for ieeefp.h... no
>> checking endian.h usability... yes
>> checking endian.h presence... yes
>> checking for endian.h... yes
>> checking sys/isa_defs.h usability... no
>> checking sys/isa_defs.h presence... no
>> checking for sys/isa_defs.h... no
>> checking machine/endian.h usability... no
>> checking machine/endian.h presence... no
>> checking for machine/endian.h... no
>> checking machine/param.h usability... no
>> checking machine/param.h presence... no
>> checking for machine/param.h... no
>> checking sys/machine.h usability... no
>> checking sys/machine.h presence... no
>> checking for sys/machine.h... no
>> checking fp.h usability... no
>> checking fp.h presence... no
>> checking for fp.h... no
>> checking locale.h usability... yes
>> checking locale.h presence... yes
>> checking for locale.h... yes
>> checking float.h usability... yes
>> checking float.h presence... yes
>> checking for float.h... yes
>> checking for inttypes.h... (cached) yes
>> checking gconv.h usability... yes
>> checking gconv.h presence... yes
>> checking for gconv.h... yes
>> checking for sys/types.h... (cached) yes
>> checking sys/ipc.h usability... yes
>> checking sys/ipc.h presence... yes
>> checking for sys/ipc.h... yes
>> checking sys/sem.h usability... yes
>> checking sys/sem.h presence... yes
>> checking for sys/sem.h... yes
>> checking for ld version... 2411
>> checking for ld that supports -Wl,-z,relro... yes
>> *checking for sin in -lm... configure: error: Link tests are not allowed
>> after GCC_NO_EXECUTABLES.*
>> make[3]: *** [configure-target-libstdc++-v3] 错误 1
>> make[3]:正在离开目录 `/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0'
>> make[2]: *** [all] 错误 2
>> make[2]:正在离开目录 `/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0'
>> make[1]: *** [cc1] 错误 2
>> make[1]:正在离开目录 `/home/nancy/work/build-open64-svn'
>> make: *** [build] 错误 2
>>
>> I have libstdc++4.8-dev, lib64stdc++4.8.dev libm installed on my
>> desktop.
>> No problem to build $gcc test.c -lm.
>>
>>
>>
>> On Mon, Aug 25, 2014 at 4:05 PM, Jian-Xin Lai <la...@gm...> wrote:
>>
>>> David's patch is the key to this problem. You may need to revise his
>>> patch with the information from the gcc output.
>>>
>>>
>>> 2014-08-25 15:50 GMT+08:00 Nancy <nan...@gm...>:
>>>
>>> nancy@nancy-ThinkPad-T61:~$ gcc -m32 -print-file-name=crti.o
>>>> /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crti.o
>>>> nancy@nancy-ThinkPad-T61:~$ gcc -m32 -print-file-name=crtn.o
>>>> /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crtn.o
>>>> nancy@nancy-ThinkPad-T61:~$ gcc -m64 -print-file-name=crti.o
>>>> /usr/lib/gcc/i686-linux-gnu/4.8/../../../../lib64/crti.o
>>>> nancy@nancy-ThinkPad-T61:~$ gcc -m64 -print-file-name=crtn.o
>>>> /usr/lib/gcc/i686-linux-gnu/4.8/../../../../lib64/crtn.o
>>>>
>>>> I think the file exist and uses correctly or the crtendS.o,
>>>> crtendBeginS.o ... could not rebuilt successfully.
>>>>
>>>> nancy@nancy-ThinkPad-T61
>>>> :~/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc$
>>>> */home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc*
>>>> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
>>>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
>>>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
>>>> -isystem
>>>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
>>>> -isystem
>>>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
>>>> -O2 -O2 -O2 -DTARG_X8664 -DIN_GCC -W -Wall -Wwrite-strings
>>>> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
>>>> ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
>>>> -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1
>>>> -Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp
>>>> libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o
>>>> libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o
>>>> libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o
>>>> libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o
>>>> libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o
>>>> libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o
>>>> libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o
>>>> libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o
>>>> libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o
>>>> libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o
>>>> libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o
>>>> libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o
>>>> libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o
>>>> libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o
>>>> libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o
>>>> libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o
>>>> libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o
>>>> libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o
>>>> libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o
>>>> libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o
>>>> libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o
>>>> libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o
>>>> libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o
>>>> libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o
>>>> libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o
>>>> libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o
>>>> libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so &&
>>>> if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1
>>>> ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp
>>>> ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so
>>>>
>>>> I don't known where you give the newly built "xgcc"'s parameters( in
>>>> Makefile or somewhere ), that place miss the path in front of crti.o crtn.o.
>>>>
>>>>
>>>> On Mon, Aug 25, 2014 at 3:13 PM, Jian-Xin Lai <la...@gm...>
>>>> wrote:
>>>>
>>>>> Have you tried to compile a small program with gcc -m32? Does it work?
>>>>> If yes, you may try the following commands:
>>>>> gcc -m32 -print-file-name=crti.o
>>>>> gcc -m32 -print-file-name=crtn.o
>>>>> gcc -m64 -print-file-name=crti.o
>>>>> gcc -m64 -print-file-name=crtn.o
>>>>>
>>>>> On my system, the outputs are:
>>>>> > gcc -m32 -print-file-name=crti.o
>>>>> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib/crti.o
>>>>> > gcc -m32 -print-file-name=crtn.o
>>>>> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib/crtn.o
>>>>> > gcc -m64 -print-file-name=crti.o
>>>>> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crti.o
>>>>> > gcc -m64 -print-file-name=crtn.o
>>>>> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crtn.o
>>>>>
>>>>> You may check these outputs and make sure the files exist and are used
>>>>> correctly.
>>>>>
>>>>>
>>>>>
>>>>> 2014-08-25 15:06 GMT+08:00 Nancy <nan...@gm...>:
>>>>>
>>>>> The patch still not working for me. Still the same error. Though the
>>>>>> value of MULTILIB_OSDIRNAMES changes, but still no path in front of
>>>>>> crti.o, crtn.o :(
>>>>>>
>>>>>> > By the way, x32 is a different ABI (
>>>>>> http://en.wikipedia.org/wiki/X32_ABI).
>>>>>> Thanks for this information :)
>>>>>>
>>>>>> On Mon, Aug 25, 2014 at 12:08 PM, David Coakley <dco...@gm...>
>>>>>> wrote:
>>>>>> > Here is a revised patch that I think will work for you:
>>>>>> >
>>>>>> > Index: osprey-gcc-4.2.0/gcc/config/i386/t-linux64
>>>>>> > ===================================================================
>>>>>> > --- osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (revision 4115)
>>>>>> > +++ osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (working copy)
>>>>>> > @@ -6,7 +6,7 @@
>>>>>> >
>>>>>> > MULTILIB_OPTIONS = m64/m32
>>>>>> > MULTILIB_DIRNAMES = 64 32
>>>>>> > -MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep
>>>>>> "ELF
>>>>>> > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -d
>>>>>> /usr/lib64 ] ;
>>>>>> > then echo "../lib64 ../lib32" ; else echo "../lib/x86_64-linux-gnu
>>>>>> > ../lib32" ; fi)
>>>>>> > +MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep
>>>>>> "ELF
>>>>>> > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f
>>>>>> > /usr/lib64/crti.o -a -f /usr/lib32/crti.o ] ; then echo "../lib64
>>>>>> ../lib32"
>>>>>> > ; else echo "../lib/x86_64-linux-gnu ../lib/i386-linux-gnu" ; fi)
>>>>>> >
>>>>>> > LIBGCC = stmp-multilib
>>>>>> > INSTALL_LIBGCC = install-multilib
>>>>>> >
>>>>>> >
>>>>>> > By the way, x32 is a different ABI (
>>>>>> http://en.wikipedia.org/wiki/X32_ABI).
>>>>>> >
>>>>>> > -David
>>>>>> >
>>>>>> >
>>>>>> > On Sat, Aug 23, 2014 at 11:55 PM, Nancy <nan...@gm...>
>>>>>> wrote:
>>>>>> >>
>>>>>> >> On Sun, Aug 24, 2014 at 1:28 PM, David Coakley <dco...@gm...>
>>>>>> wrote:
>>>>>> >> >
>>>>>> >> > Does /usr/lib32/crti.o exist on your system? If not, try
>>>>>> installing the
>>>>>> >> > 'gcc-multilib' package.
>>>>>> >>
>>>>>> >> No, there's no /usr/lib32 folder exist but both /usr/libx32/crti.o
>>>>>> >> /usr/lib64/crti.o do exist. And I have 'gcc-multilib' installed
>>>>>> already.
>>>>>> >>
>>>>>> >>
>>>>>> >> > Here are all the packages I installed on a desktop 64-bit Ubuntu
>>>>>> 14.04
>>>>>> >> > system:
>>>>>> >> >
>>>>>> >> > build-essential
>>>>>> >> > subversion
>>>>>> >> > flex
>>>>>> >> > bison
>>>>>> >> > g++
>>>>>> >> > gfortran
>>>>>> >> > gcc-multilib
>>>>>> >> > gfortran-multilib
>>>>>> >>
>>>>>> >> I installed the missing gfortran & gfortran-multilib.
>>>>>> >>
>>>>>> >> Replace 'lib32' to 'libx32':
>>>>>> >> MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep
>>>>>> "ELF
>>>>>> >> 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f
>>>>>> >> /usr/lib64/crti.o ] ; then echo "../lib64 ../libx32" ; else echo
>>>>>> >> "../lib/x86_64-linux-gnu ../libx32" ; fi)
>>>>>> >>
>>>>>> >> or not replace it, still the same error. This software enviroment
>>>>>> has no
>>>>>> >> problem building gcc 4.8.2 or LLVM with debug mode opened from
>>>>>> sourcecode.
>>>>>> >>
>>>>>> >>
>>>>>> >> --
>>>>>> >> Best Regards,
>>>>>> >> Yu Rong Tan
>>>>>> >
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best Regards,
>>>>>> Yu Rong Tan
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Lai Jian-Xin
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards,
>>>> Yu Rong Tan
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Lai Jian-Xin
>>>
>>
>>
>>
>> --
>> Best Regards,
>> Yu Rong Tan
>>
>
>
>
> --
> Regards,
> Lai Jian-Xin
>
--
Best Regards,
Yu Rong Tan
|
|
From: Jian-Xin L. <la...@gm...> - 2014-08-27 05:04:07
|
There should be a file named config.log in the libstdc++-v3 and you may get
more clues fro there. Now the build scripts has built the gcc 4.2
(/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc)
and tried to use it to build the libstdc++ shipped with gcc 4.2 (otherwise
there will be compatibility issues between the front end and stdc++).
Basically, the system libm should be used.
2014-08-26 19:57 GMT+08:00 Nancy <nan...@gm...>:
> I don't think so. MULTILIB_OSDIRNAMES controls multilib build, cri.o,
> crtn.o do not belong to multilib.
>
> Here's a walk a round way:
> Modify the contents of file
> "build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/specs":
> *startfile:
> %{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
> */usr/lib/i386-linux-gnu/*crti.o%s
> %{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}
>
> endfile:
> %{ffast-math|funsafe-math-optimizations:crtfastmath.o%s}
> %{shared|pie:crtendS.o%s;:crtend.o%s} */usr/lib/gcc/i386-linux-gnu/*
> crtn.o%s
>
> This "specs" file was automatically generated by
> osprey-gcc-4.2.0/gcc/Makefile.in:1409 rules
> $(SPECS): xgcc$(exeext)
> $(GCC_FOR_TARGET) -dumpspecs > tmp-specs
> mv tmp-specs $(SPECS)
>
> I don't known how to control GCC_FOR_TARGET correctly.
>
> NEW issue:
> make[4]:正在离开目录
> `/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc'
> Checking multilib configuration for libstdc++-v3...
> Configuring in x86_64-redhat-linux/libstdc++-v3
> configure: loading cache ./config.cache
> *checking build system type... (cached) x86_64-redhat-linux-gnu*
> *checking host system type... (cached) x86_64-redhat-linux-gnu*
> *checking target system type... (cached) x86_64-redhat-linux-gnu*
> *How come to get this result, my machine is i686 smp Ubuntu?*
>
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for gawk... (cached) gawk
> checking whether make sets $(MAKE)... (cached) yes
> checking how to run the C preprocessor... (cached)
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
> -E
> checking for egrep... (cached) grep -E
> checking for x86_64-redhat-linux-gcc... (cached)
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
> checking for suffix of object files... (cached) o
> checking whether we are using the GNU C compiler... (cached) yes
> checking whether
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
> accepts -g... (cached) yes
> checking for
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
> option to accept ANSI C... (cached) none needed
> checking for x86_64-redhat-linux-g++... (cached)
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> -shared-libgcc
> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc
> -nostdinc++
> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src
> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src/.libs
> -m32
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
> checking whether we are using the GNU C++ compiler... (cached) yes
> checking whether
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> -shared-libgcc
> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc
> -nostdinc++
> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src
> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src/.libs
> -m32
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
> accepts -g... (cached) yes
> checking whether ln -s works... yes
> checking for x86_64-redhat-linux-as... (cached)
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/as
> checking for x86_64-redhat-linux-ar... (cached) ar
> checking for x86_64-redhat-linux-ranlib... (cached) ranlib
> checking whether to enable maintainer-specific portions of Makefiles... no
> configure: CPU config directory is cpu/i486
> configure: OS config directory is os/gnu-linux
> checking for ld used by GCC... (cached)
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld
> checking if the linker
> (/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld)
> is GNU ld... (cached) yes
> checking for
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld
> option to reload object files... (cached) -r
> checking for BSD-compatible nm... (cached)
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/nm
> checking how to recognise dependant libraries... (cached) pass_all
> checking the maximum length of command line arguments... (cached) 49153
> checking for x86_64-redhat-linux-ranlib... (cached) ranlib
> checking for x86_64-redhat-linux-strip... (cached) strip
> updating cache ./config.cache
> loading cache ./config.cache within ltconfig
> checking whether -lc should be explicitly linked in... (cached) no
> checking for objdir... .libs
> checking for
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> option to produce PIC... -fPIC -DPIC
> checking if
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> PIC flag -fPIC -DPIC works... (cached) yes
> checking if
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> static flag works... (cached) no
> finding the maximum length of command line arguments... (cached) 49153
> checking if
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> supports -c -o file.o... (cached) yes
> checking if
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> supports -fno-rtti -fno-exceptions ... no
> checking whether the linker
> (/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld
> -m elf_i386) supports shared libraries... yes
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking command to parse
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/nm
> output... failed
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> creating libtool
> updating cache ./config.cache
> configure: loading cache ./config.cache
> checking how to run the C++ preprocessor...
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> -shared-libgcc
> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc
> -nostdinc++
> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src
> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src/.libs
> -m32
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
> -E
> loading cache ./config.cache within ltconfig
> checking host system type... x86_64-redhat-linux-gnu
> checking build system type... x86_64-redhat-linux-gnu
> checking for objdir... .libs
> checking for
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> option to produce PIC... -fPIC -DPIC
> checking if
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> PIC flag -fPIC -DPIC works... yes
> checking if
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> static flag -static works... no
> finding the maximum length of command line arguments... (cached) 49153
> checking if
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> supports -c -o file.o... (cached) yes
> checking if
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> supports -fno-rtti -fno-exceptions ... yes
> checking whether the linker
> (/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld
> -m elf_i386) supports shared libraries...
> checking how to hardcode library paths into programs... immediate
> checking whether stripping libraries is possible... yes
> checking dynamic linker characteristics... GNU/Linux ld.so
> checking command to parse
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/nm
> output... failed
> checking if libtool supports shared libraries... yes
> checking whether to build shared libraries... yes
> checking whether to build static libraries... yes
> appending configuration tag "CXX" to libtool
> checking for exception model to use... call frame
> checking for compiler with PCH support... yes
> checking for enabled PCH... yes
> checking for underlying I/O to use... stdio
> checking for ANSI C header files... yes
> checking for sys/types.h... yes
> checking for sys/stat.h... yes
> checking for stdlib.h... yes
> checking for string.h... yes
> checking for memory.h... yes
> checking for strings.h... yes
> checking for inttypes.h... yes
> checking for stdint.h... yes
> checking for unistd.h... yes
> checking for C locale to use... generic
> checking for std::allocator base class... new
> configure: "C" header strategy set to c_std
> checking for enabled long long specializations... yes
> checking wchar.h usability... yes
> checking wchar.h presence... yes
> checking for wchar.h... yes
> checking for mbstate_t... yes
> checking wctype.h usability... yes
> checking wctype.h presence... yes
> checking for wctype.h... yes
> checking for enabled wchar_t specializations... yes
> checking for ISO C99 support in <math.h>... yes
> checking complex.h usability... yes
> checking complex.h presence... yes
> checking for complex.h... yes
> checking for ISO C99 support in <complex.h>... yes
> checking for ISO C99 support in <stdio.h>... yes
> checking for ISO C99 support in <stdlib.h>... yes
> checking for ISO C99 support in <wchar.h>... yes
> checking for fully enabled ISO C99 support... yes
> configure: Debug build flags set to -g3 -O0
> checking for additional debug build... no
> checking for extra compiler flags for building...
> checking for thread model used by GCC... posix
> checking for atomic builtins... no
> checking for g++ that supports -ffunction-sections -fdata-sections... yes
> checking nan.h usability... no
> checking nan.h presence... no
> checking for nan.h... no
> checking ieeefp.h usability... no
> checking ieeefp.h presence... no
> checking for ieeefp.h... no
> checking endian.h usability... yes
> checking endian.h presence... yes
> checking for endian.h... yes
> checking sys/isa_defs.h usability... no
> checking sys/isa_defs.h presence... no
> checking for sys/isa_defs.h... no
> checking machine/endian.h usability... no
> checking machine/endian.h presence... no
> checking for machine/endian.h... no
> checking machine/param.h usability... no
> checking machine/param.h presence... no
> checking for machine/param.h... no
> checking sys/machine.h usability... no
> checking sys/machine.h presence... no
> checking for sys/machine.h... no
> checking fp.h usability... no
> checking fp.h presence... no
> checking for fp.h... no
> checking locale.h usability... yes
> checking locale.h presence... yes
> checking for locale.h... yes
> checking float.h usability... yes
> checking float.h presence... yes
> checking for float.h... yes
> checking for inttypes.h... (cached) yes
> checking gconv.h usability... yes
> checking gconv.h presence... yes
> checking for gconv.h... yes
> checking for sys/types.h... (cached) yes
> checking sys/ipc.h usability... yes
> checking sys/ipc.h presence... yes
> checking for sys/ipc.h... yes
> checking sys/sem.h usability... yes
> checking sys/sem.h presence... yes
> checking for sys/sem.h... yes
> checking for ld version... 2411
> checking for ld that supports -Wl,-z,relro... yes
> *checking for sin in -lm... configure: error: Link tests are not allowed
> after GCC_NO_EXECUTABLES.*
> make[3]: *** [configure-target-libstdc++-v3] 错误 1
> make[3]:正在离开目录 `/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0'
> make[2]: *** [all] 错误 2
> make[2]:正在离开目录 `/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0'
> make[1]: *** [cc1] 错误 2
> make[1]:正在离开目录 `/home/nancy/work/build-open64-svn'
> make: *** [build] 错误 2
>
> I have libstdc++4.8-dev, lib64stdc++4.8.dev libm installed on my desktop.
> No problem to build $gcc test.c -lm.
>
>
>
> On Mon, Aug 25, 2014 at 4:05 PM, Jian-Xin Lai <la...@gm...> wrote:
>
>> David's patch is the key to this problem. You may need to revise his
>> patch with the information from the gcc output.
>>
>>
>> 2014-08-25 15:50 GMT+08:00 Nancy <nan...@gm...>:
>>
>> nancy@nancy-ThinkPad-T61:~$ gcc -m32 -print-file-name=crti.o
>>> /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crti.o
>>> nancy@nancy-ThinkPad-T61:~$ gcc -m32 -print-file-name=crtn.o
>>> /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crtn.o
>>> nancy@nancy-ThinkPad-T61:~$ gcc -m64 -print-file-name=crti.o
>>> /usr/lib/gcc/i686-linux-gnu/4.8/../../../../lib64/crti.o
>>> nancy@nancy-ThinkPad-T61:~$ gcc -m64 -print-file-name=crtn.o
>>> /usr/lib/gcc/i686-linux-gnu/4.8/../../../../lib64/crtn.o
>>>
>>> I think the file exist and uses correctly or the crtendS.o,
>>> crtendBeginS.o ... could not rebuilt successfully.
>>>
>>> nancy@nancy-ThinkPad-T61
>>> :~/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc$
>>> */home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc*
>>> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
>>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
>>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
>>> -isystem
>>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
>>> -isystem
>>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
>>> -O2 -O2 -O2 -DTARG_X8664 -DIN_GCC -W -Wall -Wwrite-strings
>>> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
>>> ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
>>> -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1
>>> -Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp
>>> libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o
>>> libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o
>>> libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o
>>> libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o
>>> libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o
>>> libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o
>>> libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o
>>> libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o
>>> libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o
>>> libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o
>>> libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o
>>> libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o
>>> libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o
>>> libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o
>>> libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o
>>> libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o
>>> libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o
>>> libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o
>>> libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o
>>> libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o
>>> libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o
>>> libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o
>>> libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o
>>> libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o
>>> libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o
>>> libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o
>>> libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so &&
>>> if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1
>>> ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp
>>> ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so
>>>
>>> I don't known where you give the newly built "xgcc"'s parameters( in
>>> Makefile or somewhere ), that place miss the path in front of crti.o crtn.o.
>>>
>>>
>>> On Mon, Aug 25, 2014 at 3:13 PM, Jian-Xin Lai <la...@gm...> wrote:
>>>
>>>> Have you tried to compile a small program with gcc -m32? Does it work?
>>>> If yes, you may try the following commands:
>>>> gcc -m32 -print-file-name=crti.o
>>>> gcc -m32 -print-file-name=crtn.o
>>>> gcc -m64 -print-file-name=crti.o
>>>> gcc -m64 -print-file-name=crtn.o
>>>>
>>>> On my system, the outputs are:
>>>> > gcc -m32 -print-file-name=crti.o
>>>> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib/crti.o
>>>> > gcc -m32 -print-file-name=crtn.o
>>>> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib/crtn.o
>>>> > gcc -m64 -print-file-name=crti.o
>>>> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crti.o
>>>> > gcc -m64 -print-file-name=crtn.o
>>>> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crtn.o
>>>>
>>>> You may check these outputs and make sure the files exist and are used
>>>> correctly.
>>>>
>>>>
>>>>
>>>> 2014-08-25 15:06 GMT+08:00 Nancy <nan...@gm...>:
>>>>
>>>> The patch still not working for me. Still the same error. Though the
>>>>> value of MULTILIB_OSDIRNAMES changes, but still no path in front of
>>>>> crti.o, crtn.o :(
>>>>>
>>>>> > By the way, x32 is a different ABI (
>>>>> http://en.wikipedia.org/wiki/X32_ABI).
>>>>> Thanks for this information :)
>>>>>
>>>>> On Mon, Aug 25, 2014 at 12:08 PM, David Coakley <dco...@gm...>
>>>>> wrote:
>>>>> > Here is a revised patch that I think will work for you:
>>>>> >
>>>>> > Index: osprey-gcc-4.2.0/gcc/config/i386/t-linux64
>>>>> > ===================================================================
>>>>> > --- osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (revision 4115)
>>>>> > +++ osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (working copy)
>>>>> > @@ -6,7 +6,7 @@
>>>>> >
>>>>> > MULTILIB_OPTIONS = m64/m32
>>>>> > MULTILIB_DIRNAMES = 64 32
>>>>> > -MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep
>>>>> "ELF
>>>>> > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -d
>>>>> /usr/lib64 ] ;
>>>>> > then echo "../lib64 ../lib32" ; else echo "../lib/x86_64-linux-gnu
>>>>> > ../lib32" ; fi)
>>>>> > +MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep
>>>>> "ELF
>>>>> > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f
>>>>> > /usr/lib64/crti.o -a -f /usr/lib32/crti.o ] ; then echo "../lib64
>>>>> ../lib32"
>>>>> > ; else echo "../lib/x86_64-linux-gnu ../lib/i386-linux-gnu" ; fi)
>>>>> >
>>>>> > LIBGCC = stmp-multilib
>>>>> > INSTALL_LIBGCC = install-multilib
>>>>> >
>>>>> >
>>>>> > By the way, x32 is a different ABI (
>>>>> http://en.wikipedia.org/wiki/X32_ABI).
>>>>> >
>>>>> > -David
>>>>> >
>>>>> >
>>>>> > On Sat, Aug 23, 2014 at 11:55 PM, Nancy <nan...@gm...>
>>>>> wrote:
>>>>> >>
>>>>> >> On Sun, Aug 24, 2014 at 1:28 PM, David Coakley <dco...@gm...>
>>>>> wrote:
>>>>> >> >
>>>>> >> > Does /usr/lib32/crti.o exist on your system? If not, try
>>>>> installing the
>>>>> >> > 'gcc-multilib' package.
>>>>> >>
>>>>> >> No, there's no /usr/lib32 folder exist but both /usr/libx32/crti.o
>>>>> >> /usr/lib64/crti.o do exist. And I have 'gcc-multilib' installed
>>>>> already.
>>>>> >>
>>>>> >>
>>>>> >> > Here are all the packages I installed on a desktop 64-bit Ubuntu
>>>>> 14.04
>>>>> >> > system:
>>>>> >> >
>>>>> >> > build-essential
>>>>> >> > subversion
>>>>> >> > flex
>>>>> >> > bison
>>>>> >> > g++
>>>>> >> > gfortran
>>>>> >> > gcc-multilib
>>>>> >> > gfortran-multilib
>>>>> >>
>>>>> >> I installed the missing gfortran & gfortran-multilib.
>>>>> >>
>>>>> >> Replace 'lib32' to 'libx32':
>>>>> >> MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep
>>>>> "ELF
>>>>> >> 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f
>>>>> >> /usr/lib64/crti.o ] ; then echo "../lib64 ../libx32" ; else echo
>>>>> >> "../lib/x86_64-linux-gnu ../libx32" ; fi)
>>>>> >>
>>>>> >> or not replace it, still the same error. This software enviroment
>>>>> has no
>>>>> >> problem building gcc 4.8.2 or LLVM with debug mode opened from
>>>>> sourcecode.
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> Best Regards,
>>>>> >> Yu Rong Tan
>>>>> >
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best Regards,
>>>>> Yu Rong Tan
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Regards,
>>>> Lai Jian-Xin
>>>>
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Yu Rong Tan
>>>
>>
>>
>>
>> --
>> Regards,
>> Lai Jian-Xin
>>
>
>
>
> --
> Best Regards,
> Yu Rong Tan
>
--
Regards,
Lai Jian-Xin
|
|
From: Nancy <nan...@gm...> - 2014-08-26 11:57:32
|
I don't think so. MULTILIB_OSDIRNAMES controls multilib build, cri.o,
crtn.o do not belong to multilib.
Here's a walk a round way:
Modify the contents of file
"build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/specs":
*startfile:
%{!shared: %{pg|p|profile:gcrt1.o%s;pie:Scrt1.o%s;:crt1.o%s}}
*/usr/lib/i386-linux-gnu/*crti.o%s
%{static:crtbeginT.o%s;shared|pie:crtbeginS.o%s;:crtbegin.o%s}
endfile:
%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s}
%{shared|pie:crtendS.o%s;:crtend.o%s} */usr/lib/gcc/i386-linux-gnu/*
crtn.o%s
This "specs" file was automatically generated by
osprey-gcc-4.2.0/gcc/Makefile.in:1409 rules
$(SPECS): xgcc$(exeext)
$(GCC_FOR_TARGET) -dumpspecs > tmp-specs
mv tmp-specs $(SPECS)
I don't known how to control GCC_FOR_TARGET correctly.
NEW issue:
make[4]:正在离开目录
`/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc'
Checking multilib configuration for libstdc++-v3...
Configuring in x86_64-redhat-linux/libstdc++-v3
configure: loading cache ./config.cache
*checking build system type... (cached) x86_64-redhat-linux-gnu*
*checking host system type... (cached) x86_64-redhat-linux-gnu*
*checking target system type... (cached) x86_64-redhat-linux-gnu*
*How come to get this result, my machine is i686 smp Ubuntu?*
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... (cached) gawk
checking whether make sets $(MAKE)... (cached) yes
checking how to run the C preprocessor... (cached)
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
-B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
-E
checking for egrep... (cached) grep -E
checking for x86_64-redhat-linux-gcc... (cached)
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
-B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
checking for suffix of object files... (cached) o
checking whether we are using the GNU C compiler... (cached) yes
checking whether
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
-B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
accepts -g... (cached) yes
checking for
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
-B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
option to accept ANSI C... (cached) none needed
checking for x86_64-redhat-linux-g++... (cached)
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
-shared-libgcc
-B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc
-nostdinc++
-L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src
-L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src/.libs
-m32
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
-shared-libgcc
-B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc
-nostdinc++
-L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src
-L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src/.libs
-m32
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
accepts -g... (cached) yes
checking whether ln -s works... yes
checking for x86_64-redhat-linux-as... (cached)
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/as
checking for x86_64-redhat-linux-ar... (cached) ar
checking for x86_64-redhat-linux-ranlib... (cached) ranlib
checking whether to enable maintainer-specific portions of Makefiles... no
configure: CPU config directory is cpu/i486
configure: OS config directory is os/gnu-linux
checking for ld used by GCC... (cached)
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld
checking if the linker
(/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld)
is GNU ld... (cached) yes
checking for
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld
option to reload object files... (cached) -r
checking for BSD-compatible nm... (cached)
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/nm
checking how to recognise dependant libraries... (cached) pass_all
checking the maximum length of command line arguments... (cached) 49153
checking for x86_64-redhat-linux-ranlib... (cached) ranlib
checking for x86_64-redhat-linux-strip... (cached) strip
updating cache ./config.cache
loading cache ./config.cache within ltconfig
checking whether -lc should be explicitly linked in... (cached) no
checking for objdir... .libs
checking for
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
option to produce PIC... -fPIC -DPIC
checking if
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
PIC flag -fPIC -DPIC works... (cached) yes
checking if
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
static flag works... (cached) no
finding the maximum length of command line arguments... (cached) 49153
checking if
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
supports -c -o file.o... (cached) yes
checking if
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
supports -fno-rtti -fno-exceptions ... no
checking whether the linker
(/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld
-m elf_i386) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking command to parse
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/nm
output... failed
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
creating libtool
updating cache ./config.cache
configure: loading cache ./config.cache
checking how to run the C++ preprocessor...
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
-shared-libgcc
-B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc
-nostdinc++
-L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src
-L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/x86_64-redhat-linux/libstdc++-v3/src/.libs
-m32
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
-B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
-isystem
/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
-E
loading cache ./config.cache within ltconfig
checking host system type... x86_64-redhat-linux-gnu
checking build system type... x86_64-redhat-linux-gnu
checking for objdir... .libs
checking for
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
option to produce PIC... -fPIC -DPIC
checking if
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
PIC flag -fPIC -DPIC works... yes
checking if
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
static flag -static works... no
finding the maximum length of command line arguments... (cached) 49153
checking if
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
supports -c -o file.o... (cached) yes
checking if
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
supports -fno-rtti -fno-exceptions ... yes
checking whether the linker
(/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect-ld
-m elf_i386) supports shared libraries...
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking command to parse
/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/nm
output... failed
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
appending configuration tag "CXX" to libtool
checking for exception model to use... call frame
checking for compiler with PCH support... yes
checking for enabled PCH... yes
checking for underlying I/O to use... stdio
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for C locale to use... generic
checking for std::allocator base class... new
configure: "C" header strategy set to c_std
checking for enabled long long specializations... yes
checking wchar.h usability... yes
checking wchar.h presence... yes
checking for wchar.h... yes
checking for mbstate_t... yes
checking wctype.h usability... yes
checking wctype.h presence... yes
checking for wctype.h... yes
checking for enabled wchar_t specializations... yes
checking for ISO C99 support in <math.h>... yes
checking complex.h usability... yes
checking complex.h presence... yes
checking for complex.h... yes
checking for ISO C99 support in <complex.h>... yes
checking for ISO C99 support in <stdio.h>... yes
checking for ISO C99 support in <stdlib.h>... yes
checking for ISO C99 support in <wchar.h>... yes
checking for fully enabled ISO C99 support... yes
configure: Debug build flags set to -g3 -O0
checking for additional debug build... no
checking for extra compiler flags for building...
checking for thread model used by GCC... posix
checking for atomic builtins... no
checking for g++ that supports -ffunction-sections -fdata-sections... yes
checking nan.h usability... no
checking nan.h presence... no
checking for nan.h... no
checking ieeefp.h usability... no
checking ieeefp.h presence... no
checking for ieeefp.h... no
checking endian.h usability... yes
checking endian.h presence... yes
checking for endian.h... yes
checking sys/isa_defs.h usability... no
checking sys/isa_defs.h presence... no
checking for sys/isa_defs.h... no
checking machine/endian.h usability... no
checking machine/endian.h presence... no
checking for machine/endian.h... no
checking machine/param.h usability... no
checking machine/param.h presence... no
checking for machine/param.h... no
checking sys/machine.h usability... no
checking sys/machine.h presence... no
checking for sys/machine.h... no
checking fp.h usability... no
checking fp.h presence... no
checking for fp.h... no
checking locale.h usability... yes
checking locale.h presence... yes
checking for locale.h... yes
checking float.h usability... yes
checking float.h presence... yes
checking for float.h... yes
checking for inttypes.h... (cached) yes
checking gconv.h usability... yes
checking gconv.h presence... yes
checking for gconv.h... yes
checking for sys/types.h... (cached) yes
checking sys/ipc.h usability... yes
checking sys/ipc.h presence... yes
checking for sys/ipc.h... yes
checking sys/sem.h usability... yes
checking sys/sem.h presence... yes
checking for sys/sem.h... yes
checking for ld version... 2411
checking for ld that supports -Wl,-z,relro... yes
*checking for sin in -lm... configure: error: Link tests are not allowed
after GCC_NO_EXECUTABLES.*
make[3]: *** [configure-target-libstdc++-v3] 错误 1
make[3]:正在离开目录 `/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0'
make[2]: *** [all] 错误 2
make[2]:正在离开目录 `/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0'
make[1]: *** [cc1] 错误 2
make[1]:正在离开目录 `/home/nancy/work/build-open64-svn'
make: *** [build] 错误 2
I have libstdc++4.8-dev, lib64stdc++4.8.dev libm installed on my desktop.
No problem to build $gcc test.c -lm.
On Mon, Aug 25, 2014 at 4:05 PM, Jian-Xin Lai <la...@gm...> wrote:
> David's patch is the key to this problem. You may need to revise his patch
> with the information from the gcc output.
>
>
> 2014-08-25 15:50 GMT+08:00 Nancy <nan...@gm...>:
>
> nancy@nancy-ThinkPad-T61:~$ gcc -m32 -print-file-name=crti.o
>> /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crti.o
>> nancy@nancy-ThinkPad-T61:~$ gcc -m32 -print-file-name=crtn.o
>> /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crtn.o
>> nancy@nancy-ThinkPad-T61:~$ gcc -m64 -print-file-name=crti.o
>> /usr/lib/gcc/i686-linux-gnu/4.8/../../../../lib64/crti.o
>> nancy@nancy-ThinkPad-T61:~$ gcc -m64 -print-file-name=crtn.o
>> /usr/lib/gcc/i686-linux-gnu/4.8/../../../../lib64/crtn.o
>>
>> I think the file exist and uses correctly or the crtendS.o,
>> crtendBeginS.o ... could not rebuilt successfully.
>>
>> nancy@nancy-ThinkPad-T61
>> :~/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc$
>> */home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc*
>> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
>> -isystem
>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
>> -O2 -O2 -O2 -DTARG_X8664 -DIN_GCC -W -Wall -Wwrite-strings
>> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
>> ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
>> -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1
>> -Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp
>> libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o
>> libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o
>> libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o
>> libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o
>> libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o
>> libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o
>> libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o
>> libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o
>> libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o
>> libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o
>> libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o
>> libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o
>> libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o
>> libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o
>> libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o
>> libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o
>> libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o
>> libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o
>> libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o
>> libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o
>> libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o
>> libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o
>> libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o
>> libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o
>> libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o
>> libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o
>> libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so &&
>> if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1
>> ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp
>> ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so
>>
>> I don't known where you give the newly built "xgcc"'s parameters( in
>> Makefile or somewhere ), that place miss the path in front of crti.o crtn.o.
>>
>>
>> On Mon, Aug 25, 2014 at 3:13 PM, Jian-Xin Lai <la...@gm...> wrote:
>>
>>> Have you tried to compile a small program with gcc -m32? Does it work?
>>> If yes, you may try the following commands:
>>> gcc -m32 -print-file-name=crti.o
>>> gcc -m32 -print-file-name=crtn.o
>>> gcc -m64 -print-file-name=crti.o
>>> gcc -m64 -print-file-name=crtn.o
>>>
>>> On my system, the outputs are:
>>> > gcc -m32 -print-file-name=crti.o
>>> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib/crti.o
>>> > gcc -m32 -print-file-name=crtn.o
>>> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib/crtn.o
>>> > gcc -m64 -print-file-name=crti.o
>>> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crti.o
>>> > gcc -m64 -print-file-name=crtn.o
>>> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crtn.o
>>>
>>> You may check these outputs and make sure the files exist and are used
>>> correctly.
>>>
>>>
>>>
>>> 2014-08-25 15:06 GMT+08:00 Nancy <nan...@gm...>:
>>>
>>> The patch still not working for me. Still the same error. Though the
>>>> value of MULTILIB_OSDIRNAMES changes, but still no path in front of
>>>> crti.o, crtn.o :(
>>>>
>>>> > By the way, x32 is a different ABI (
>>>> http://en.wikipedia.org/wiki/X32_ABI).
>>>> Thanks for this information :)
>>>>
>>>> On Mon, Aug 25, 2014 at 12:08 PM, David Coakley <dco...@gm...>
>>>> wrote:
>>>> > Here is a revised patch that I think will work for you:
>>>> >
>>>> > Index: osprey-gcc-4.2.0/gcc/config/i386/t-linux64
>>>> > ===================================================================
>>>> > --- osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (revision 4115)
>>>> > +++ osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (working copy)
>>>> > @@ -6,7 +6,7 @@
>>>> >
>>>> > MULTILIB_OPTIONS = m64/m32
>>>> > MULTILIB_DIRNAMES = 64 32
>>>> > -MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep
>>>> "ELF
>>>> > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -d
>>>> /usr/lib64 ] ;
>>>> > then echo "../lib64 ../lib32" ; else echo "../lib/x86_64-linux-gnu
>>>> > ../lib32" ; fi)
>>>> > +MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep
>>>> "ELF
>>>> > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f
>>>> > /usr/lib64/crti.o -a -f /usr/lib32/crti.o ] ; then echo "../lib64
>>>> ../lib32"
>>>> > ; else echo "../lib/x86_64-linux-gnu ../lib/i386-linux-gnu" ; fi)
>>>> >
>>>> > LIBGCC = stmp-multilib
>>>> > INSTALL_LIBGCC = install-multilib
>>>> >
>>>> >
>>>> > By the way, x32 is a different ABI (
>>>> http://en.wikipedia.org/wiki/X32_ABI).
>>>> >
>>>> > -David
>>>> >
>>>> >
>>>> > On Sat, Aug 23, 2014 at 11:55 PM, Nancy <nan...@gm...>
>>>> wrote:
>>>> >>
>>>> >> On Sun, Aug 24, 2014 at 1:28 PM, David Coakley <dco...@gm...>
>>>> wrote:
>>>> >> >
>>>> >> > Does /usr/lib32/crti.o exist on your system? If not, try
>>>> installing the
>>>> >> > 'gcc-multilib' package.
>>>> >>
>>>> >> No, there's no /usr/lib32 folder exist but both /usr/libx32/crti.o
>>>> >> /usr/lib64/crti.o do exist. And I have 'gcc-multilib' installed
>>>> already.
>>>> >>
>>>> >>
>>>> >> > Here are all the packages I installed on a desktop 64-bit Ubuntu
>>>> 14.04
>>>> >> > system:
>>>> >> >
>>>> >> > build-essential
>>>> >> > subversion
>>>> >> > flex
>>>> >> > bison
>>>> >> > g++
>>>> >> > gfortran
>>>> >> > gcc-multilib
>>>> >> > gfortran-multilib
>>>> >>
>>>> >> I installed the missing gfortran & gfortran-multilib.
>>>> >>
>>>> >> Replace 'lib32' to 'libx32':
>>>> >> MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep
>>>> "ELF
>>>> >> 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f
>>>> >> /usr/lib64/crti.o ] ; then echo "../lib64 ../libx32" ; else echo
>>>> >> "../lib/x86_64-linux-gnu ../libx32" ; fi)
>>>> >>
>>>> >> or not replace it, still the same error. This software enviroment
>>>> has no
>>>> >> problem building gcc 4.8.2 or LLVM with debug mode opened from
>>>> sourcecode.
>>>> >>
>>>> >>
>>>> >> --
>>>> >> Best Regards,
>>>> >> Yu Rong Tan
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Best Regards,
>>>> Yu Rong Tan
>>>>
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Lai Jian-Xin
>>>
>>
>>
>>
>> --
>> Best Regards,
>> Yu Rong Tan
>>
>
>
>
> --
> Regards,
> Lai Jian-Xin
>
--
Best Regards,
Yu Rong Tan
|
|
From: Jian-Xin L. <la...@gm...> - 2014-08-25 08:05:21
|
David's patch is the key to this problem. You may need to revise his patch with the information from the gcc output. 2014-08-25 15:50 GMT+08:00 Nancy <nan...@gm...>: > nancy@nancy-ThinkPad-T61:~$ gcc -m32 -print-file-name=crti.o > /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crti.o > nancy@nancy-ThinkPad-T61:~$ gcc -m32 -print-file-name=crtn.o > /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crtn.o > nancy@nancy-ThinkPad-T61:~$ gcc -m64 -print-file-name=crti.o > /usr/lib/gcc/i686-linux-gnu/4.8/../../../../lib64/crti.o > nancy@nancy-ThinkPad-T61:~$ gcc -m64 -print-file-name=crtn.o > /usr/lib/gcc/i686-linux-gnu/4.8/../../../../lib64/crtn.o > > I think the file exist and uses correctly or the crtendS.o, crtendBeginS.o > ... could not rebuilt successfully. > > nancy@nancy-ThinkPad-T61 > :~/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc$ > */home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc* > -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32 > -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/ > -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/ > -isystem > /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include > -isystem > /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include > -O2 -O2 -O2 -DTARG_X8664 -DIN_GCC -W -Wall -Wwrite-strings > -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem > ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 > -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 > -Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp > libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o > libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o > libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o > libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o > libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o > libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o > libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o > libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o > libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o > libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o > libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o > libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o > libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o > libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o > libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o > libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o > libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o > libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o > libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o > libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o > libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o > libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o > libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o > libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o > libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o > libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o > libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so && > if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 > ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp > ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so > > I don't known where you give the newly built "xgcc"'s parameters( in > Makefile or somewhere ), that place miss the path in front of crti.o crtn.o. > > > On Mon, Aug 25, 2014 at 3:13 PM, Jian-Xin Lai <la...@gm...> wrote: > >> Have you tried to compile a small program with gcc -m32? Does it work? If >> yes, you may try the following commands: >> gcc -m32 -print-file-name=crti.o >> gcc -m32 -print-file-name=crtn.o >> gcc -m64 -print-file-name=crti.o >> gcc -m64 -print-file-name=crtn.o >> >> On my system, the outputs are: >> > gcc -m32 -print-file-name=crti.o >> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib/crti.o >> > gcc -m32 -print-file-name=crtn.o >> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib/crtn.o >> > gcc -m64 -print-file-name=crti.o >> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crti.o >> > gcc -m64 -print-file-name=crtn.o >> /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crtn.o >> >> You may check these outputs and make sure the files exist and are used >> correctly. >> >> >> >> 2014-08-25 15:06 GMT+08:00 Nancy <nan...@gm...>: >> >> The patch still not working for me. Still the same error. Though the >>> value of MULTILIB_OSDIRNAMES changes, but still no path in front of >>> crti.o, crtn.o :( >>> >>> > By the way, x32 is a different ABI ( >>> http://en.wikipedia.org/wiki/X32_ABI). >>> Thanks for this information :) >>> >>> On Mon, Aug 25, 2014 at 12:08 PM, David Coakley <dco...@gm...> >>> wrote: >>> > Here is a revised patch that I think will work for you: >>> > >>> > Index: osprey-gcc-4.2.0/gcc/config/i386/t-linux64 >>> > =================================================================== >>> > --- osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (revision 4115) >>> > +++ osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (working copy) >>> > @@ -6,7 +6,7 @@ >>> > >>> > MULTILIB_OPTIONS = m64/m32 >>> > MULTILIB_DIRNAMES = 64 32 >>> > -MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF >>> > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -d >>> /usr/lib64 ] ; >>> > then echo "../lib64 ../lib32" ; else echo "../lib/x86_64-linux-gnu >>> > ../lib32" ; fi) >>> > +MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF >>> > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f >>> > /usr/lib64/crti.o -a -f /usr/lib32/crti.o ] ; then echo "../lib64 >>> ../lib32" >>> > ; else echo "../lib/x86_64-linux-gnu ../lib/i386-linux-gnu" ; fi) >>> > >>> > LIBGCC = stmp-multilib >>> > INSTALL_LIBGCC = install-multilib >>> > >>> > >>> > By the way, x32 is a different ABI ( >>> http://en.wikipedia.org/wiki/X32_ABI). >>> > >>> > -David >>> > >>> > >>> > On Sat, Aug 23, 2014 at 11:55 PM, Nancy <nan...@gm...> >>> wrote: >>> >> >>> >> On Sun, Aug 24, 2014 at 1:28 PM, David Coakley <dco...@gm...> >>> wrote: >>> >> > >>> >> > Does /usr/lib32/crti.o exist on your system? If not, try >>> installing the >>> >> > 'gcc-multilib' package. >>> >> >>> >> No, there's no /usr/lib32 folder exist but both /usr/libx32/crti.o >>> >> /usr/lib64/crti.o do exist. And I have 'gcc-multilib' installed >>> already. >>> >> >>> >> >>> >> > Here are all the packages I installed on a desktop 64-bit Ubuntu >>> 14.04 >>> >> > system: >>> >> > >>> >> > build-essential >>> >> > subversion >>> >> > flex >>> >> > bison >>> >> > g++ >>> >> > gfortran >>> >> > gcc-multilib >>> >> > gfortran-multilib >>> >> >>> >> I installed the missing gfortran & gfortran-multilib. >>> >> >>> >> Replace 'lib32' to 'libx32': >>> >> MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF >>> >> 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f >>> >> /usr/lib64/crti.o ] ; then echo "../lib64 ../libx32" ; else echo >>> >> "../lib/x86_64-linux-gnu ../libx32" ; fi) >>> >> >>> >> or not replace it, still the same error. This software enviroment has >>> no >>> >> problem building gcc 4.8.2 or LLVM with debug mode opened from >>> sourcecode. >>> >> >>> >> >>> >> -- >>> >> Best Regards, >>> >> Yu Rong Tan >>> > >>> > >>> >>> >>> >>> -- >>> Best Regards, >>> Yu Rong Tan >>> >> >> >> >> -- >> Regards, >> Lai Jian-Xin >> > > > > -- > Best Regards, > Yu Rong Tan > -- Regards, Lai Jian-Xin |
|
From: Nancy <nan...@gm...> - 2014-08-25 07:50:34
|
nancy@nancy-ThinkPad-T61:~$ gcc -m32 -print-file-name=crti.o /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crti.o nancy@nancy-ThinkPad-T61:~$ gcc -m32 -print-file-name=crtn.o /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crtn.o nancy@nancy-ThinkPad-T61:~$ gcc -m64 -print-file-name=crti.o /usr/lib/gcc/i686-linux-gnu/4.8/../../../../lib64/crti.o nancy@nancy-ThinkPad-T61:~$ gcc -m64 -print-file-name=crtn.o /usr/lib/gcc/i686-linux-gnu/4.8/../../../../lib64/crtn.o I think the file exist and uses correctly or the crtendS.o, crtendBeginS.o ... could not rebuilt successfully. nancy@nancy-ThinkPad-T61 :~/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc$ */home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc* -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/ -m32 -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/ -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/ -isystem /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include -isystem /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include -O2 -O2 -O2 -DTARG_X8664 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so I don't known where you give the newly built "xgcc"'s parameters( in Makefile or somewhere ), that place miss the path in front of crti.o crtn.o. On Mon, Aug 25, 2014 at 3:13 PM, Jian-Xin Lai <la...@gm...> wrote: > Have you tried to compile a small program with gcc -m32? Does it work? If > yes, you may try the following commands: > gcc -m32 -print-file-name=crti.o > gcc -m32 -print-file-name=crtn.o > gcc -m64 -print-file-name=crti.o > gcc -m64 -print-file-name=crtn.o > > On my system, the outputs are: > > gcc -m32 -print-file-name=crti.o > /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib/crti.o > > gcc -m32 -print-file-name=crtn.o > /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib/crtn.o > > gcc -m64 -print-file-name=crti.o > /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crti.o > > gcc -m64 -print-file-name=crtn.o > /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crtn.o > > You may check these outputs and make sure the files exist and are used > correctly. > > > > 2014-08-25 15:06 GMT+08:00 Nancy <nan...@gm...>: > > The patch still not working for me. Still the same error. Though the >> value of MULTILIB_OSDIRNAMES changes, but still no path in front of >> crti.o, crtn.o :( >> >> > By the way, x32 is a different ABI ( >> http://en.wikipedia.org/wiki/X32_ABI). >> Thanks for this information :) >> >> On Mon, Aug 25, 2014 at 12:08 PM, David Coakley <dco...@gm...> >> wrote: >> > Here is a revised patch that I think will work for you: >> > >> > Index: osprey-gcc-4.2.0/gcc/config/i386/t-linux64 >> > =================================================================== >> > --- osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (revision 4115) >> > +++ osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (working copy) >> > @@ -6,7 +6,7 @@ >> > >> > MULTILIB_OPTIONS = m64/m32 >> > MULTILIB_DIRNAMES = 64 32 >> > -MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF >> > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -d >> /usr/lib64 ] ; >> > then echo "../lib64 ../lib32" ; else echo "../lib/x86_64-linux-gnu >> > ../lib32" ; fi) >> > +MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF >> > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f >> > /usr/lib64/crti.o -a -f /usr/lib32/crti.o ] ; then echo "../lib64 >> ../lib32" >> > ; else echo "../lib/x86_64-linux-gnu ../lib/i386-linux-gnu" ; fi) >> > >> > LIBGCC = stmp-multilib >> > INSTALL_LIBGCC = install-multilib >> > >> > >> > By the way, x32 is a different ABI ( >> http://en.wikipedia.org/wiki/X32_ABI). >> > >> > -David >> > >> > >> > On Sat, Aug 23, 2014 at 11:55 PM, Nancy <nan...@gm...> >> wrote: >> >> >> >> On Sun, Aug 24, 2014 at 1:28 PM, David Coakley <dco...@gm...> >> wrote: >> >> > >> >> > Does /usr/lib32/crti.o exist on your system? If not, try installing >> the >> >> > 'gcc-multilib' package. >> >> >> >> No, there's no /usr/lib32 folder exist but both /usr/libx32/crti.o >> >> /usr/lib64/crti.o do exist. And I have 'gcc-multilib' installed >> already. >> >> >> >> >> >> > Here are all the packages I installed on a desktop 64-bit Ubuntu >> 14.04 >> >> > system: >> >> > >> >> > build-essential >> >> > subversion >> >> > flex >> >> > bison >> >> > g++ >> >> > gfortran >> >> > gcc-multilib >> >> > gfortran-multilib >> >> >> >> I installed the missing gfortran & gfortran-multilib. >> >> >> >> Replace 'lib32' to 'libx32': >> >> MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF >> >> 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f >> >> /usr/lib64/crti.o ] ; then echo "../lib64 ../libx32" ; else echo >> >> "../lib/x86_64-linux-gnu ../libx32" ; fi) >> >> >> >> or not replace it, still the same error. This software enviroment has >> no >> >> problem building gcc 4.8.2 or LLVM with debug mode opened from >> sourcecode. >> >> >> >> >> >> -- >> >> Best Regards, >> >> Yu Rong Tan >> > >> > >> >> >> >> -- >> Best Regards, >> Yu Rong Tan >> > > > > -- > Regards, > Lai Jian-Xin > -- Best Regards, Yu Rong Tan |
|
From: Jian-Xin L. <la...@gm...> - 2014-08-25 07:13:56
|
Have you tried to compile a small program with gcc -m32? Does it work? If yes, you may try the following commands: gcc -m32 -print-file-name=crti.o gcc -m32 -print-file-name=crtn.o gcc -m64 -print-file-name=crti.o gcc -m64 -print-file-name=crtn.o On my system, the outputs are: > gcc -m32 -print-file-name=crti.o /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib/crti.o > gcc -m32 -print-file-name=crtn.o /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib/crtn.o > gcc -m64 -print-file-name=crti.o /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crti.o > gcc -m64 -print-file-name=crtn.o /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../lib64/crtn.o You may check these outputs and make sure the files exist and are used correctly. 2014-08-25 15:06 GMT+08:00 Nancy <nan...@gm...>: > The patch still not working for me. Still the same error. Though the > value of MULTILIB_OSDIRNAMES changes, but still no path in front of > crti.o, crtn.o :( > > > By the way, x32 is a different ABI (http://en.wikipedia.org/wiki/X32_ABI > ). > Thanks for this information :) > > On Mon, Aug 25, 2014 at 12:08 PM, David Coakley <dco...@gm...> > wrote: > > Here is a revised patch that I think will work for you: > > > > Index: osprey-gcc-4.2.0/gcc/config/i386/t-linux64 > > =================================================================== > > --- osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (revision 4115) > > +++ osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (working copy) > > @@ -6,7 +6,7 @@ > > > > MULTILIB_OPTIONS = m64/m32 > > MULTILIB_DIRNAMES = 64 32 > > -MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF > > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -d /usr/lib64 > ] ; > > then echo "../lib64 ../lib32" ; else echo "../lib/x86_64-linux-gnu > > ../lib32" ; fi) > > +MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF > > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f > > /usr/lib64/crti.o -a -f /usr/lib32/crti.o ] ; then echo "../lib64 > ../lib32" > > ; else echo "../lib/x86_64-linux-gnu ../lib/i386-linux-gnu" ; fi) > > > > LIBGCC = stmp-multilib > > INSTALL_LIBGCC = install-multilib > > > > > > By the way, x32 is a different ABI (http://en.wikipedia.org/wiki/X32_ABI > ). > > > > -David > > > > > > On Sat, Aug 23, 2014 at 11:55 PM, Nancy <nan...@gm...> wrote: > >> > >> On Sun, Aug 24, 2014 at 1:28 PM, David Coakley <dco...@gm...> > wrote: > >> > > >> > Does /usr/lib32/crti.o exist on your system? If not, try installing > the > >> > 'gcc-multilib' package. > >> > >> No, there's no /usr/lib32 folder exist but both /usr/libx32/crti.o > >> /usr/lib64/crti.o do exist. And I have 'gcc-multilib' installed already. > >> > >> > >> > Here are all the packages I installed on a desktop 64-bit Ubuntu 14.04 > >> > system: > >> > > >> > build-essential > >> > subversion > >> > flex > >> > bison > >> > g++ > >> > gfortran > >> > gcc-multilib > >> > gfortran-multilib > >> > >> I installed the missing gfortran & gfortran-multilib. > >> > >> Replace 'lib32' to 'libx32': > >> MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF > >> 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f > >> /usr/lib64/crti.o ] ; then echo "../lib64 ../libx32" ; else echo > >> "../lib/x86_64-linux-gnu ../libx32" ; fi) > >> > >> or not replace it, still the same error. This software enviroment has no > >> problem building gcc 4.8.2 or LLVM with debug mode opened from > sourcecode. > >> > >> > >> -- > >> Best Regards, > >> Yu Rong Tan > > > > > > > > -- > Best Regards, > Yu Rong Tan > -- Regards, Lai Jian-Xin |
|
From: Nancy <nan...@gm...> - 2014-08-25 07:06:47
|
The patch still not working for me. Still the same error. Though the value of MULTILIB_OSDIRNAMES changes, but still no path in front of crti.o, crtn.o :( > By the way, x32 is a different ABI (http://en.wikipedia.org/wiki/X32_ABI). Thanks for this information :) On Mon, Aug 25, 2014 at 12:08 PM, David Coakley <dco...@gm...> wrote: > Here is a revised patch that I think will work for you: > > Index: osprey-gcc-4.2.0/gcc/config/i386/t-linux64 > =================================================================== > --- osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (revision 4115) > +++ osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (working copy) > @@ -6,7 +6,7 @@ > > MULTILIB_OPTIONS = m64/m32 > MULTILIB_DIRNAMES = 64 32 > -MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -d /usr/lib64 ] ; > then echo "../lib64 ../lib32" ; else echo "../lib/x86_64-linux-gnu > ../lib32" ; fi) > +MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f > /usr/lib64/crti.o -a -f /usr/lib32/crti.o ] ; then echo "../lib64 ../lib32" > ; else echo "../lib/x86_64-linux-gnu ../lib/i386-linux-gnu" ; fi) > > LIBGCC = stmp-multilib > INSTALL_LIBGCC = install-multilib > > > By the way, x32 is a different ABI (http://en.wikipedia.org/wiki/X32_ABI). > > -David > > > On Sat, Aug 23, 2014 at 11:55 PM, Nancy <nan...@gm...> wrote: >> >> On Sun, Aug 24, 2014 at 1:28 PM, David Coakley <dco...@gm...> wrote: >> > >> > Does /usr/lib32/crti.o exist on your system? If not, try installing the >> > 'gcc-multilib' package. >> >> No, there's no /usr/lib32 folder exist but both /usr/libx32/crti.o >> /usr/lib64/crti.o do exist. And I have 'gcc-multilib' installed already. >> >> >> > Here are all the packages I installed on a desktop 64-bit Ubuntu 14.04 >> > system: >> > >> > build-essential >> > subversion >> > flex >> > bison >> > g++ >> > gfortran >> > gcc-multilib >> > gfortran-multilib >> >> I installed the missing gfortran & gfortran-multilib. >> >> Replace 'lib32' to 'libx32': >> MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF >> 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f >> /usr/lib64/crti.o ] ; then echo "../lib64 ../libx32" ; else echo >> "../lib/x86_64-linux-gnu ../libx32" ; fi) >> >> or not replace it, still the same error. This software enviroment has no >> problem building gcc 4.8.2 or LLVM with debug mode opened from sourcecode. >> >> >> -- >> Best Regards, >> Yu Rong Tan > > -- Best Regards, Yu Rong Tan |
|
From: David C. <dco...@gm...> - 2014-08-25 04:08:52
|
Here is a revised patch that I think will work for you: Index: osprey-gcc-4.2.0/gcc/config/i386/t-linux64 =================================================================== --- osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (revision 4115) +++ osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (working copy) @@ -6,7 +6,7 @@ MULTILIB_OPTIONS = m64/m32 MULTILIB_DIRNAMES = 64 32 -MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -d /usr/lib64 ] ; then echo "../lib64 ../lib32" ; else echo "../lib/x86_64-linux-gnu ../lib32" ; fi) +MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f /usr/lib64/crti.o -a -f /usr/lib32/crti.o ] ; then echo "../lib64 ../lib32" ; else echo "../lib/x86_64-linux-gnu ../lib/i386-linux-gnu" ; fi) LIBGCC = stmp-multilib INSTALL_LIBGCC = install-multilib By the way, x32 is a different ABI (http://en.wikipedia.org/wiki/X32_ABI). -David On Sat, Aug 23, 2014 at 11:55 PM, Nancy <nan...@gm...> wrote: > On Sun, Aug 24, 2014 at 1:28 PM, David Coakley <dco...@gm...> wrote: > > > > Does /usr/lib32/crti.o exist on your system? If not, try installing the > 'gcc-multilib' package. > > No, there's no /usr/lib32 folder exist but both /usr/libx32/crti.o > /usr/lib64/crti.o do exist. And I have 'gcc-multilib' installed already. > > > > Here are all the packages I installed on a desktop 64-bit Ubuntu 14.04 > system: > > > > build-essential > > subversion > > flex > > bison > > g++ > > gfortran > > gcc-multilib > > gfortran-multilib > > I installed the missing gfortran & gfortran-multilib. > > Replace 'lib32' to 'libx32': > MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF > 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f > /usr/lib64/crti.o ] ; then echo "../lib64 ../libx32" ; else echo > "../lib/x86_64-linux-gnu ../libx32" ; fi) > > or not replace it, still the same error. This software enviroment has no > problem building gcc 4.8.2 or LLVM with debug mode opened from sourcecode. > > > -- > Best Regards, > Yu Rong Tan > |
|
From: Nancy <nan...@gm...> - 2014-08-24 06:55:40
|
On Sun, Aug 24, 2014 at 1:28 PM, David Coakley <dco...@gm...> wrote: > > Does /usr/lib32/crti.o exist on your system? If not, try installing the 'gcc-multilib' package. No, there's no /usr/lib32 folder exist but both /usr/libx32/crti.o /usr/lib64/crti.o do exist. And I have 'gcc-multilib' installed already. > Here are all the packages I installed on a desktop 64-bit Ubuntu 14.04 system: > > build-essential > subversion > flex > bison > g++ > gfortran > gcc-multilib > gfortran-multilib I installed the missing gfortran & gfortran-multilib. Replace 'lib32' to 'libx32': MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f /usr/lib64/crti.o ] ; then echo "../lib64 ../libx32" ; else echo "../lib/x86_64-linux-gnu ../libx32" ; fi) or not replace it, still the same error. This software enviroment has no problem building gcc 4.8.2 or LLVM with debug mode opened from sourcecode. -- Best Regards, Yu Rong Tan |
|
From: David C. <dco...@gm...> - 2014-08-24 05:28:33
|
Does /usr/lib32/crti.o exist on your system? If not, try installing the
'gcc-multilib' package.
Here are all the packages I installed on a desktop 64-bit Ubuntu 14.04
system:
build-essential
subversion
flex
bison
g++
gfortran
gcc-multilib
gfortran-multilib
Hope that helps,
-David
On Sat, Aug 23, 2014 at 9:10 PM, Nancy <nan...@gm...> wrote:
> Hi David,
>
> I'm sorry this this fix does not work for me. Please use
> non-Plain-test-mode to see this email. That could be more clear.
>
> nancy@nancy-ThinkPad-T61:~/work$ if file /usr/lib/crti.o -Lb |fgrep "ELF
> 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ *-d
> /usr/lib64 *] ; then echo "../lib64 ../lib32" ; else echo
> "../lib/x86_64-linux-gnu ../lib32" ; fi
> *../lib64 ../lib32*
> nancy@nancy-ThinkPad-T61:~/work$ if file /usr/lib/crti.o -Lb |fgrep "ELF
> 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ *-f
> /usr/lib64/crti.o* ] ; then echo "../lib64 ../lib32" ; else echo
> "../lib/x86_64-linux-gnu ../lib32" ; fi
> *../lib64 ../lib32*
> nancy@nancy-ThinkPad-T61:~/work$
>
> Thanks for your information. I try to figure out where's going wrong, by
> manually excecuting the error command with "-v" option.
> nancy@nancy-ThinkPad-T61:~/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc$
> */home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
> -v *-B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/
> -m32
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
> -isystem
> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
> -O2 -O2 -O2 -DTARG_X8664 -DIN_GCC -W -Wall -Wwrite-strings
> -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
> ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2
> -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1
> -Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp
> libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o
> libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o
> libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o
> libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o
> libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o
> libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o
> libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o
> libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o
> libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o
> libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o
> libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o
> libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o
> libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o
> libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o
> libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o
> libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o
> libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o
> libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o
> libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o
> libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o
> libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o
> libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o
> libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o
> libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o
> libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o
> libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o
> libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc && rm -f ./libgcc_s.so &&
> if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1
> ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp
> ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so
> Reading specs from
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/specs
> Target: x86_64-redhat-linux
> Configured with: ../../open64-svn/./osprey-gcc-4.2.0/configure
> --prefix=/home/nancy/toolchains/open64/open64-gcc-4.2.0 --with-gnu-as
> --with-gnu-ld --enable-languages=c,c++ --disable-bootstrap
> --disable-libmudflap --disable-libssp --disable-checking
> --enable-threads=posix --enable-tls --with-system-zlib
> --enable-__cxa_atexit --srcdir=../../open64-svn/./osprey-gcc-4.2.0
> --host=x86_64-redhat-linux --target=x86_64-redhat-linux
> Thread model: posix
> gcc version 4.2.0
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/collect2
> --eh-frame-hdr -m elf_i386 -shared -o ./libgcc_s.so.1.tmp *crti.o* /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/crtbeginS.o
> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/32
> -L/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc
> --soname=libgcc_s.so.1 --version-script=libgcc/./libgcc.map
> libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o
> libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o
> libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o
> libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o
> libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o
> libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o
> libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o
> libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o
> libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o
> libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o
> libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o
> libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o
> libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o
> libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o
> libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o
> libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o
> libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o
> libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o
> libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o
> libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o
> libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o
> libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o
> libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o
> libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o
> libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o
> libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o
> libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc
> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/crtendS.o
> *crtn.o*
> /usr/local/bin/ld: error: cannot open crti.o:
> error: cannot open crtn.o:
> collect2: ld returned 1 exit status
>
> I wonder why open64 only rebuild crtendS.o, crtendBeginS.o ..... but do
> not rebuild crti.o, crtn.o?
>
> I tried to find out the correct path of crtn.o crti.o by step below:
> nancy@nancy-ThinkPad-T61:*~/work/build-open64-svn$ grep "crtn.o" . -rn*
> ./osprey/cygnus/ld/Makefile:177:HOSTING_LIBS = -L`dirname \`${CC}
> --print-file-name=libc.so\`` `if [ -f ../gcc/libgcc.a ]; then
> libgcc=../gcc/libgcc.a; else libgcc=\`${CC} -print-libgcc-file-name\`; fi;
> if [ -f ../gcc/libgcc_eh.a ]; then libgcc="$libgcc ../gcc/libgcc_eh.a";
> else libgcc_eh=\`${CC} -print-file-name=libgcc_eh.a\`; if [ x"$libgcc_eh"
> != xlibgcc_eh.a ]; then libgcc="$libgcc $libgcc_eh"; fi; fi; echo
> --start-group $libgcc -lc --end-group` `if [ -f ../gcc/crtend.o ]; then
> echo ../gcc/crtend.o; else ${CC} --print-file-name=crtend.o; fi` `${CC}
> --print-file-name=crtn.o`
>
> ./osprey/cygnus/ld/config.log:82: /usr/lib/gcc/i686-linux-gnu/4.8/collect2
> --sysroot=/ --build-id --eh-frame-hdr -m elf_i386 --hash-style=gnu
> --as-needed -shared -z relro -o conftest
> /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crti.o
> /usr/lib/gcc/i686-linux-gnu/4.8/crtbeginS.o
> -L/usr/lib/gcc/i686-linux-gnu/4.8
> -L/usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu
> -L/usr/lib/gcc/i686-linux-gnu/4.8/../../../../lib -L/lib/i386-linux-gnu
> -L/lib/../lib -L/usr/lib/i386-linux-gnu -L/usr/lib/../lib
> -L/usr/lib/gcc/i686-linux-gnu/4.8/../../.. conftest.o -soname conftest
> -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
> --no-as-needed /usr/lib/gcc/i686-linux-gnu/4.8/crtendS.o
> /usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/crtn.o
>
> ./osprey/cygnus/ld/config.status:129:s%@HOSTING_LIBS@%-L`dirname \`${CC}
> --print-file-name=libc.so\`` `if [ -f ../gcc/libgcc.a ]; then
> libgcc=../gcc/libgcc.a; else libgcc=\`${CC} -print-libgcc-file-name\`; fi;
> if [ -f ../gcc/libgcc_eh.a ]; then libgcc="$libgcc ../gcc/libgcc_eh.a";
> else libgcc_eh=\`${CC} -print-file-name=libgcc_eh.a\`; if [ x"$libgcc_eh"
> != xlibgcc_eh.a ]; then libgcc="$libgcc $libgcc_eh"; fi; fi; echo
> --start-group $libgcc -lc --end-group` `if [ -f ../gcc/crtend.o ]; then
> echo ../gcc/crtend.o; else ${CC} --print-file-name=crtend.o; fi` `${CC}
> --print-file-name=crtn.o`%g
> .....
>
> Compile successed by manually adding path
> "/usr/lib/gcc/i686-linux-gnu/4.8/../../../i386-linux-gnu/" in front of
> crti.o and crtn.o in the command line. I don't known where to add it to
> take effect the whole project.
>
>
>
>
> On Sat, Aug 23, 2014 at 11:50 AM, David Coakley <dco...@gm...>
> wrote:
>
>> The linker issue is due to a bug in the way we find the path to the CRT
>> object files (crti.o, etc.). We were assuming that if /usr/lib64 exists,
>> that's where we would find the 64-bit versions. On Ubuntu 14.04, there is
>> a /usr/lib64, but that is not where the CRT object files live.
>>
>> Here is the proposed fix (the change is just to the test after the
>> 'elif'):
>>
>> Index: osprey-gcc-4.2.0/gcc/config/i386/t-linux64
>> ===================================================================
>> --- osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (revision 4115)
>> +++ osprey-gcc-4.2.0/gcc/config/i386/t-linux64 (working copy)
>> @@ -6,7 +6,7 @@
>>
>> MULTILIB_OPTIONS = m64/m32
>> MULTILIB_DIRNAMES = 64 32
>> -MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF
>> 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -d /usr/lib64 ]
>> ; then echo "../lib64 ../lib32" ; else echo "../lib/x86_64-linux-gnu
>> ../lib32" ; fi)
>> +MULTILIB_OSDIRNAMES = $(shell if file /usr/lib/crti.o -Lb |fgrep "ELF
>> 32-bit" >/dev/null ; then echo "../lib64 ../lib"; elif [ -f
>> /usr/lib64/crti.o ] ; then echo "../lib64 ../lib32" ; else echo
>> "../lib/x86_64-linux-gnu ../lib32" ; fi)
>>
>> LIBGCC = stmp-multilib
>> INSTALL_LIBGCC = install-multilib
>>
>>
>>
>> On Fri, Aug 22, 2014 at 1:27 AM, Nancy <nan...@gm...> wrote:
>>
>>> On Fri, Aug 22, 2014 at 2:46 PM, David Coakley <dco...@gm...>
>>> wrote:
>>> > There was a change to the way that siginfo is defined. I was able to
>>> build
>>> > on Fedora 19 (gcc 4.8.3) with the following change:
>>> >
>>> > Index: osprey-gcc-4.2.0/gcc/config/i386/linux-unwind.h
>>> > ===================================================================
>>> > --- osprey-gcc-4.2.0/gcc/config/i386/linux-unwind.h (revision 4114)
>>> > +++ osprey-gcc-4.2.0/gcc/config/i386/linux-unwind.h (working copy)
>>> > @@ -137,9 +137,17 @@
>>> > {
>>> > struct rt_sigframe {
>>> > int sig;
>>> > +#ifdef __have_siginfo_t
>>> > + siginfo_t *pinfo;
>>> > +#else
>>> > struct siginfo *pinfo;
>>> > +#endif
>>> > void *puc;
>>> > +#ifdef __have_siginfo_t
>>> > + siginfo_t info;
>>> > +#else
>>> > struct siginfo info;
>>> > +#endif
>>> > struct ucontext uc;
>>> > } *rt_ = context->cfa;
>>> > /* The void * cast is necessary to avoid an aliasing warning.
>>> >
>>> >
>>> > If it helps, I can check that in to the trunk as well.
>>> >
>>> Hi David,
>>>
>>> Your patch works for me again :) Thanks a lot!
>>>
>>> New linker issue:
>>> /home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/xgcc
>>> -B/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc/
>>> -m32
>>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/bin/
>>> -B/home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/lib/
>>> -isystem
>>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/include
>>> -isystem
>>> /home/nancy/toolchains/open64/open64-gcc-4.2.0/x86_64-redhat-linux/sys-include
>>> -O2 -O2 -O0 -g -DIs_True_On -DTARG_X8664 -DIN_GCC -W -Wall
>>> -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
>>> -Wold-style-definition -isystem ./include -fPIC -g
>>> -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared
>>> -nodefaultlibs -Wl,--soname=libgcc_s.so.1
>>> -Wl,--version-script=libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp
>>> libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o
>>> libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o
>>> libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o
>>> libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o
>>> libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o
>>> libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o
>>> libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o
>>> libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o
>>> libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o
>>> libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o
>>> libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o
>>> libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o
>>> libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o
>>> libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o
>>> libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o
>>> libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o
>>> libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_fixunssfsi_s.o
>>> libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o
>>> libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o
>>> libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o
>>> libgcc/./_fixunsdfdi_s.o libgcc/./_floatdidf_s.o
>>> libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o
>>> libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o
>>> libgcc/./_floatundixf_s.o libgcc/./_fixtfdi_s.o
>>> libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o
>>> libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o
>>> libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o
>>> libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o
>>> libgcc/./unwind-dw2-fde-glibc_s.o libgcc/./unwind-sjlj_s.o
>>> libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc && rm -f
>>> ./libgcc_s.so && if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1
>>> ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp
>>> ./libgcc_s.so.1 && ln -s libgcc_s.so.1 ./libgcc_s.so
>>> /usr/local/bin/ld: error: cannot open crti.o: 没有那个文件或目录(file or folder
>>> do not exist)
>>> /usr/local/bin/ld: error: cannot open crtn.o: 没有那个文件或目录(file or folder
>>> do not exist)
>>> collect2: ld returned 1 exit status
>>> make[5]: *** [libgcc_s.so] 错误 1
>>> make[5]:正在离开目录
>>> `/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc'
>>> make[4]: *** [stmp-multilib] 错误 2
>>> make[4]:正在离开目录
>>> `/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0/host-unknown/gcc'
>>> make[3]: *** [all-gcc] 错误 2
>>> make[3]:正在离开目录 `/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0'
>>> make[2]: *** [all] 错误 2
>>> make[2]:正在离开目录 `/home/nancy/work/build-open64-svn/osprey-gcc-4.2.0'
>>> make[1]: *** [cc1] 错误 2
>>> make[1]:正在离开目录 `/home/nancy/work/build-open64-svn'
>>> make: *** [build] 错误 2
>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Yu Rong Tan
>>>
>>
>>
>
>
> --
> Best Regards,
> Yu Rong Tan
>
|
224 messages has been excluded from this view by a project administrator.
