On Saturday, 28 July 2012 15:52:19 UTC+8, kfiz wrote:
> System Software Overview shows '64-bit Kernel and Extensions: Yes'. > As I said I used to run it with 32-bit but I changed that with a keyboard > combination. In contrast to the other guys from the link you posted I've > successfully installed the 64-bit dmg. But building sage 5.1 from source > code somehow doesn't work for me..
> are you installing Xcode from the official place
Basically, a static library cannot be bigger that 4GB on your toolchain. A workaround is to not to build "universal" libraries, i.. anything that works on 32 as well as on 64 bit (i.e x86 and x86_64) systems.
> Am Samstag, 28. Juli 2012 05:00:58 UTC+2 schrieb Dima Pasechnik:
>> On Saturday, 28 July 2012 01:55:13 UTC+8, kfiz wrote:
>>> Hmmh, I have a macbook pro mid 2009, Core 2 Duo. Some Core 2 Duos >>> mis-represent themselves as 64 bit? How could I check wether my machine >>> does that? It used to run under 32-bit, but than I switched it to 64-bit >>> via an official apple command. The systemprofiler states 64-bit...
>> What does System Software Overview show for you? I suppose that you see
>> 64-bit Kernel and Extensions: No
>> This was discussed here and on sage-devel a little while ago, as it is >> indeed confusing: the processor is 64-bit, but the kernel is 32 bit. While >> some(?) 64-bit executables can be still run, it is still a 32-bit kernel... >> See
>> PS. Sorry, John, it could be that googlegroups are not as capable of >> changing the subject as we wish :(
>> As far as I know, the only way to get a 64-bit kernel for Core 2 Duo is >> to upgrade to OSX 10.7.
>>> Am Freitag, 27. Juli 2012 07:35:32 UTC+2 schrieb Dima Pasechnik:
>>>> On Friday, 27 July 2012 03:56:27 UTC+8, kfiz wrote:
>>>>> I also use Xcode 3.2.6 (freshly installed) , but building always >>>>> crashed when gcc 4.6.3 was going to be installed on my machine. >>>>> I figured that I could install the gcc package manually, downloaded >>>>> it and ran the installation...with the same result. >>>>> really don't know what the problem is...
>>>> what is the hardware you are using? >>>> On OSX 6, some machines mis-represent themselves as 64-bit, although >>>> the system is in fact 32-bit. >>>> (e.g. Core 2 Duo ones do this) >>>> So if you try to build in a "true" 64-bit mode, it won't work then.
>>>>> Am Donnerstag, 26. Juli 2012 16:13:58 UTC+2 schrieb Dima Pasechnik:
>>>>>> On Thursday, 26 July 2012 14:21:29 UTC+8, kfiz wrote:
>>>>>>> Ok, thanks guys. I switched methods and installed with the mac osx >>>>>>> binaries. >>>>>>> seems that I have serious issues updating my current gcc compiler. >>>>>>> guess I'll just have to wait until apple updates xcode.
>>>>>> this is strange. I think many people, including several very active >>>>>> Sage developers, >>>>>> work on OSX 10.6.8 with XCode, and not having any issues. Provided it >>>>>> is Xcode 3.2.6.
>>>>>> What version of Xcode do you use?
>>>>>>> cheers
>>>>>>> doro
>>>>>>> Am Mittwoch, 25. Juli 2012 13:08:40 UTC+2 schrieb kfiz:
>>>>>>>> re-installed XCode. this time:
>>>>>>>> /usr/bin/ranlib: archive member: libbackend.a(ude) size too large >>>>>>>> (archive member extends past the end of the file) >>>>>>>> ar: internal ranlib command failed >>>>>>>> make[5]: *** [libbackend.a] Error 1 >>>>>>>> make[4]: *** [all-stage2-gcc] Error 2 >>>>>>>> make[3]: *** [stage2-bubble] Error 2 >>>>>>>> make[2]: *** [all] Error 2
>>>>>>>> real 56m5.026s >>>>>>>> user 50m8.913s >>>>>>>> sys 2m44.951s
>> A workaround is to not to build "universal" libraries, i.. anything that >> works on >> 32 as well as on 64 bit (i.e x86 and x86_64) systems.
> IIRC universal binaries should also include PPC. Am I right?
well, it used to be the case. But with Xcode 3.2.6 one has to jump extra hoops, and with Xcode 4 it seems to be impossible, as there is no OSX 10.5 frameworks for Xcode 4. (Or maybe it's not quite true, as one can reuse Xcode 3 frameworks with Xcode 4, but this is getting more an more unpleasant, AFAIK).
> A workaround is to not to build "universal" libraries, i.. anything that works on
> 32 as well as on 64 bit (i.e x86 and x86_64) systems.
> IIRC universal binaries should also include PPC. Am I right?
> well, it used to be the case. But with Xcode 3.2.6 one has to jump extra hoops, and with Xcode 4 it seems to be impossible, as there is no OSX 10.5 frameworks for Xcode 4.
> (Or maybe it's not quite true, as one can reuse Xcode 3 frameworks with Xcode 4, but this is getting more an more unpleasant, AFAIK).
>
>
> -- > Andrea Lazzarotto - http://andrealazzarotto.com > Hmmm, that seems to exactly be my bug. Yes, Dima I downloaded Xcode 3.2.6 from apple devel, but from page 4 of 7..? Are we refering to different download sections?
So, what's the smartest thing to do here..smart meaning without to much effort. ;-).
> > A workaround is to not to build "universal" libraries, i.. anything that > works on > > 32 as well as on 64 bit (i.e x86 and x86_64) systems. > > IIRC universal binaries should also include PPC. Am I right?
> > well, it used to be the case. But with Xcode 3.2.6 one has to jump extra > hoops, and with Xcode 4 it seems to be impossible, as there is no OSX 10.5 > frameworks for Xcode 4. > > (Or maybe it's not quite true, as one can reuse Xcode 3 frameworks with > Xcode 4, but this is getting more an more unpleasant, AFAIK).
> > Hmmm, that seems to exactly be my bug. Yes, Dima I downloaded Xcode > 3.2.6 from apple devel, but from page 4 of 7..? Are we refering to > different download sections? > So, what's the smartest thing to do here..smart meaning without to much > effort. ;-).
It could be that Sage is just not tested on your configuration, and you hit a real bug. I don't know. Do I get it right that you can't build the gcc that comes with Sage?
>> > A workaround is to not to build "universal" libraries, i.. anything >> that works on >> > 32 as well as on 64 bit (i.e x86 and x86_64) systems. >> > IIRC universal binaries should also include PPC. Am I right?
>> > well, it used to be the case. But with Xcode 3.2.6 one has to jump >> extra hoops, and with Xcode 4 it seems to be impossible, as there is no OSX >> 10.5 frameworks for Xcode 4. >> > (Or maybe it's not quite true, as one can reuse Xcode 3 frameworks with >> Xcode 4, but this is getting more an more unpleasant, AFAIK).
>> > Hmmm, that seems to exactly be my bug. Yes, Dima I downloaded Xcode >> 3.2.6 from apple devel, but from page 4 of 7..? Are we refering to >> different download sections? >> So, what's the smartest thing to do here..smart meaning without to much >> effort. ;-).
> It could be that Sage is just not tested on your configuration, and you > hit a real bug. > I don't know. Do I get it right that you can't build the gcc that comes > with Sage?
>>> > A workaround is to not to build "universal" libraries, i.. anything >>> that works on >>> > 32 as well as on 64 bit (i.e x86 and x86_64) systems. >>> > IIRC universal binaries should also include PPC. Am I right?
>>> > well, it used to be the case. But with Xcode 3.2.6 one has to jump >>> extra hoops, and with Xcode 4 it seems to be impossible, as there is no OSX >>> 10.5 frameworks for Xcode 4. >>> > (Or maybe it's not quite true, as one can reuse Xcode 3 frameworks >>> with Xcode 4, but this is getting more an more unpleasant, AFAIK).
>>> > Hmmm, that seems to exactly be my bug. Yes, Dima I downloaded Xcode >>> 3.2.6 from apple devel, but from page 4 of 7..? Are we refering to >>> different download sections? >>> So, what's the smartest thing to do here..smart meaning without to much >>> effort. ;-).
>> It could be that Sage is just not tested on your configuration, and you >> hit a real bug. >> I don't know. Do I get it right that you can't build the gcc that comes >> with Sage?
> Yes, that's the case.
could you post somewhere the part of your install.log, with the ranlib error on libbackend.a you mentioned earlier? One has to see with which flags the complilation/linking of libbackend.a during the installation of gcc spkg is being done. It would be good to see the actual size of libbackend.a(*) if you still have it somewhere in SAGE_LOCAL/spkg/build/...
>>>> > A workaround is to not to build "universal" libraries, i.. anything >>>> that works on >>>> > 32 as well as on 64 bit (i.e x86 and x86_64) systems. >>>> > IIRC universal binaries should also include PPC. Am I right?
>>>> > well, it used to be the case. But with Xcode 3.2.6 one has to jump >>>> extra hoops, and with Xcode 4 it seems to be impossible, as there is no OSX >>>> 10.5 frameworks for Xcode 4. >>>> > (Or maybe it's not quite true, as one can reuse Xcode 3 frameworks >>>> with Xcode 4, but this is getting more an more unpleasant, AFAIK).
>>>> > Hmmm, that seems to exactly be my bug. Yes, Dima I downloaded Xcode >>>> 3.2.6 from apple devel, but from page 4 of 7..? Are we refering to >>>> different download sections? >>>> So, what's the smartest thing to do here..smart meaning without to much >>>> effort. ;-).
>>> It could be that Sage is just not tested on your configuration, and you >>> hit a real bug. >>> I don't know. Do I get it right that you can't build the gcc that comes >>> with Sage?
>> Yes, that's the case.
> could you post somewhere the part of your install.log, with the ranlib > error on libbackend.a > you mentioned earlier? > One has to see with which flags the complilation/linking of libbackend.a > during the installation of gcc spkg is being done. It would be good to see > the actual size of libbackend.a(*) if you still have it somewhere in > SAGE_LOCAL/spkg/build/...
> deleted everything but I'll just try to build it again, then I'll post >>> the log.
>>>>> > A workaround is to not to build "universal" libraries, i.. anything >>>>> that works on >>>>> > 32 as well as on 64 bit (i.e x86 and x86_64) systems. >>>>> > IIRC universal binaries should also include PPC. Am I right?
>>>>> > well, it used to be the case. But with Xcode 3.2.6 one has to jump >>>>> extra hoops, and with Xcode 4 it seems to be impossible, as there is no OSX >>>>> 10.5 frameworks for Xcode 4. >>>>> > (Or maybe it's not quite true, as one can reuse Xcode 3 frameworks >>>>> with Xcode 4, but this is getting more an more unpleasant, AFAIK).
>>>>> > Hmmm, that seems to exactly be my bug. Yes, Dima I downloaded Xcode >>>>> 3.2.6 from apple devel, but from page 4 of 7..? Are we refering to >>>>> different download sections? >>>>> So, what's the smartest thing to do here..smart meaning without to >>>>> much effort. ;-).
>>>> It could be that Sage is just not tested on your configuration, and you >>>> hit a real bug. >>>> I don't know. Do I get it right that you can't build the gcc that comes >>>> with Sage?
>>> Yes, that's the case.
>> could you post somewhere the part of your install.log, with the ranlib >> error on libbackend.a >> you mentioned earlier? >> One has to see with which flags the complilation/linking of libbackend.a >> during the installation of gcc spkg is being done. It would be good to see >> the actual size of libbackend.a(*) if you still have it somewhere in >> SAGE_LOCAL/spkg/build/...
>> deleted everything but I'll just try to build it again, then I'll post >>>> the log.
>>>>>> > A workaround is to not to build "universal" libraries, i.. anything >>>>>> that works on >>>>>> > 32 as well as on 64 bit (i.e x86 and x86_64) systems. >>>>>> > IIRC universal binaries should also include PPC. Am I right?
>>>>>> > well, it used to be the case. But with Xcode 3.2.6 one has to jump >>>>>> extra hoops, and with Xcode 4 it seems to be impossible, as there is no OSX >>>>>> 10.5 frameworks for Xcode 4. >>>>>> > (Or maybe it's not quite true, as one can reuse Xcode 3 frameworks >>>>>> with Xcode 4, but this is getting more an more unpleasant, AFAIK).
>>>>>> > Hmmm, that seems to exactly be my bug. Yes, Dima I downloaded >>>>>> Xcode 3.2.6 from apple devel, but from page 4 of 7..? Are we refering to >>>>>> different download sections? >>>>>> So, what's the smartest thing to do here..smart meaning without to >>>>>> much effort. ;-).
>>>>> It could be that Sage is just not tested on your configuration, and >>>>> you hit a real bug. >>>>> I don't know. Do I get it right that you can't build the gcc that >>>>> comes with Sage?
>>>> Yes, that's the case.
>>> could you post somewhere the part of your install.log, with the ranlib >>> error on libbackend.a >>> you mentioned earlier? >>> One has to see with which flags the complilation/linking of libbackend.a >>> during the installation of gcc spkg is being done. It would be good to see >>> the actual size of libbackend.a(*) if you still have it somewhere in >>> SAGE_LOCAL/spkg/build/...
>>> deleted everything but I'll just try to build it again, then I'll post >>>>> the log.
> ok, so hier is part of the log:
sorry, one needs to look at parts before this. That is, parts where these .o files are produced by the compiler, gcc, and in particular what switches it is using. It would also help to know the sizes of all these .o files, or at least the maximum size...
> On Monday, 30 July 2012 03:08:01 UTC+8, kfiz wrote:
>> Am Sonntag, 29. Juli 2012 12:11:02 UTC+2 schrieb kfiz:
>>> Am Sonntag, 29. Juli 2012 11:04:13 UTC+2 schrieb Dima Pasechnik:
>>>> On Sunday, 29 July 2012 16:54:51 UTC+8, kfiz wrote:
>>>>> Am Sonntag, 29. Juli 2012 09:42:49 UTC+2 schrieb Dima Pasechnik:
>>>>>> On Sunday, 29 July 2012 14:27:22 UTC+8, kfiz wrote:
>>>>>>> Am Samstag, 28. Juli 2012 12:36:38 UTC+2 schrieb Dima Pasechnik: >>>>>>> > On Saturday, 28 July 2012 18:07:29 UTC+8, Andrea Lazzarotto >>>>>>> wrote:
>>>>>>> > A workaround is to not to build "universal" libraries, i.. >>>>>>> anything that works on >>>>>>> > 32 as well as on 64 bit (i.e x86 and x86_64) systems. >>>>>>> > IIRC universal binaries should also include PPC. Am I right?
>>>>>>> > well, it used to be the case. But with Xcode 3.2.6 one has to jump >>>>>>> extra hoops, and with Xcode 4 it seems to be impossible, as there is no OSX >>>>>>> 10.5 frameworks for Xcode 4. >>>>>>> > (Or maybe it's not quite true, as one can reuse Xcode 3 frameworks >>>>>>> with Xcode 4, but this is getting more an more unpleasant, AFAIK).
>>>>>>> > Hmmm, that seems to exactly be my bug. Yes, Dima I downloaded >>>>>>> Xcode 3.2.6 from apple devel, but from page 4 of 7..? Are we refering to >>>>>>> different download sections? >>>>>>> So, what's the smartest thing to do here..smart meaning without to >>>>>>> much effort. ;-).
>>>>>> It could be that Sage is just not tested on your configuration, and >>>>>> you hit a real bug. >>>>>> I don't know. Do I get it right that you can't build the gcc that >>>>>> comes with Sage?
>>>>> Yes, that's the case.
>>>> could you post somewhere the part of your install.log, with the ranlib >>>> error on libbackend.a >>>> you mentioned earlier? >>>> One has to see with which flags the complilation/linking of >>>> libbackend.a during the installation of gcc spkg is being done. It would >>>> be good to see the actual size of libbackend.a(*) if you still have it >>>> somewhere in SAGE_LOCAL/spkg/build/...
>>>> deleted everything but I'll just try to build it again, then I'll post >>>>>> the log.
>> ok, so hier is part of the log:
> sorry, one needs to look at parts before this. That is, parts where these > .o files are produced by the compiler, gcc, and in particular what switches > it is using. > It would also help to know the sizes of all these .o files, or at least > the maximum size...
If you look for the 1st Error in the log, you will see --------------------------------------------------------------------------- -------------------- ld: warning: in build/genautomata.o, file was built for unsupported file format which is not the architecture being linked (x86_64) Undefined symbols: "_main", referenced from: start in crt1.10.6.o ld: symbol(s) not found collect2: ld returned 1 exit status make[5]: *** [build/genautomata] Error 1 make[4]: *** [all-stage1-gcc] Error 2 make[3]: *** [stage1-bubble] Error 2 make[2]: *** [all] Error 2 --------------------------------------------------------------------------- --------------------
IMHO you should set SAGE64=yes and then build. (i.e. do export SAGE64=yes and then do "make build")
Otherwise it looks like that the compiler builds 32-bit object files.
> If you look for the 1st Error in the log, you will see
> --------------------------------------------------------------------------- -------------------- > ld: warning: in build/genautomata.o, file was built for unsupported file > format which is not the architecture being linked (x86_64) > Undefined symbols: > "_main", referenced from: > start in crt1.10.6.o > ld: symbol(s) not found > collect2: ld returned 1 exit status > make[5]: *** [build/genautomata] Error 1 > make[4]: *** [all-stage1-gcc] Error 2 > make[3]: *** [stage1-bubble] Error 2 > make[2]: *** [all] Error 2
> IMHO you should set SAGE64=yes and then build. > (i.e. do > export SAGE64=yes > and then do "make build")
> Otherwise it looks like that the compiler builds 32-bit object files.
> I think that was the problem! :-) Tried to build, everything worked fine > until package 'Maxima'..weird, because except for the final 'Error' message > (check the log) everything seems to have worked fine..
On Tuesday, 31 July 2012 10:38:52 UTC+8, kfiz wrote:
> Am Montag, 30. Juli 2012 16:25:24 UTC+2 schrieb Dima Pasechnik:
>> If you look for the 1st Error in the log, you will see
>> --------------------------------------------------------------------------- -------------------- >> ld: warning: in build/genautomata.o, file was built for unsupported file >> format which is not the architecture being linked (x86_64) >> Undefined symbols: >> "_main", referenced from: >> start in crt1.10.6.o >> ld: symbol(s) not found >> collect2: ld returned 1 exit status >> make[5]: *** [build/genautomata] Error 1 >> make[4]: *** [all-stage1-gcc] Error 2 >> make[3]: *** [stage1-bubble] Error 2 >> make[2]: *** [all] Error 2
>> IMHO you should set SAGE64=yes and then build. >> (i.e. do >> export SAGE64=yes >> and then do "make build")
>> Otherwise it looks like that the compiler builds 32-bit object files.
>> I think that was the problem! :-) Tried to build, everything worked fine >> until package 'Maxima'..weird, because except for the final 'Error' message >> (check the log) everything seems to have worked fine..
This log does not say at all why Maxima didn't build. Could you please cut the relevant (bottom) part of install.log and post it here?
> On Tuesday, 31 July 2012 10:38:52 UTC+8, kfiz wrote:
>> Am Montag, 30. Juli 2012 16:25:24 UTC+2 schrieb Dima Pasechnik:
>>> If you look for the 1st Error in the log, you will see
>>> --------------------------------------------------------------------------- -------------------- >>> ld: warning: in build/genautomata.o, file was built for unsupported file >>> format which is not the architecture being linked (x86_64) >>> Undefined symbols: >>> "_main", referenced from: >>> start in crt1.10.6.o >>> ld: symbol(s) not found >>> collect2: ld returned 1 exit status >>> make[5]: *** [build/genautomata] Error 1 >>> make[4]: *** [all-stage1-gcc] Error 2 >>> make[3]: *** [stage1-bubble] Error 2 >>> make[2]: *** [all] Error 2
>>> IMHO you should set SAGE64=yes and then build. >>> (i.e. do >>> export SAGE64=yes >>> and then do "make build")
>>> Otherwise it looks like that the compiler builds 32-bit object files.
>>> I think that was the problem! :-) Tried to build, everything worked fine >>> until package 'Maxima'..weird, because except for the final 'Error' message >>> (check the log) everything seems to have worked fine..
> This log does not say at all why Maxima didn't build. > Could you please cut the relevant (bottom) part of install.log > and post it here?
This is the part of install.log that I didn't post before:
make[1]: *** [installed/maxima-5.26.0.p0] Error 1
real 228m36.234s user 194m48.729s sys 22m18.712s Error building Sage.
On Tuesday, 31 July 2012 14:02:11 UTC+8, kfiz wrote:
> Am Dienstag, 31. Juli 2012 07:37:42 UTC+2 schrieb Dima Pasechnik:
>> On Tuesday, 31 July 2012 10:38:52 UTC+8, kfiz wrote:
>>> Am Montag, 30. Juli 2012 16:25:24 UTC+2 schrieb Dima Pasechnik:
>>>> If you look for the 1st Error in the log, you will see
>>>> --------------------------------------------------------------------------- -------------------- >>>> ld: warning: in build/genautomata.o, file was built for unsupported >>>> file format which is not the architecture being linked (x86_64) >>>> Undefined symbols: >>>> "_main", referenced from: >>>> start in crt1.10.6.o >>>> ld: symbol(s) not found >>>> collect2: ld returned 1 exit status >>>> make[5]: *** [build/genautomata] Error 1 >>>> make[4]: *** [all-stage1-gcc] Error 2 >>>> make[3]: *** [stage1-bubble] Error 2 >>>> make[2]: *** [all] Error 2
>>>> IMHO you should set SAGE64=yes and then build. >>>> (i.e. do >>>> export SAGE64=yes >>>> and then do "make build")
>>>> Otherwise it looks like that the compiler builds 32-bit object files.
>>>> I think that was the problem! :-) Tried to build, everything worked >>>> fine until package 'Maxima'..weird, because except for the final 'Error' >>>> message (check the log) everything seems to have worked fine..
>> This log does not say at all why Maxima didn't build. >> Could you please cut the relevant (bottom) part of install.log >> and post it here?
> This is the part of install.log that I didn't post before:
> real 228m36.234s > user 194m48.729s > sys 22m18.712s > Error building Sage.
> Did you refer to this?
I meant that maxima-5.26.0.p0.log you posted does not contain the log of maxima build, only the fact that it ended in a failure. In install.log there should be a part that contains a complete log of maxima build. It would start off like this:
Now building Maxima; this takes a few minutes. Since we're on MacOS X and there is a very weird bug with buffered output while building Maxima, you will not be able to see the output of the build as it occurs. Don't worry, the build process does not hang. g++ -c cf_generator.cc -Wall -fno-implicit-templates -I. -I.. -I. -I/usr/local/src/sage/sage-5.2.rc0/local -I/usr/local/src/sage/sage-5.2.rc0/local/include -DHAVE_CONFIG_H -I/usr/local/src/sage/sage-5.2.rc0/local/include -I/usr/local/src/sage/sage-5.2.rc0/local/include -I/usr/local/src/sage/sage-5.2.rc0/local/include -O2 -g -fPIC -DLIBSINGULAR -o cf_generator.o In file included from cf_generator.cc:10:0: [and lots more stuff here]
On Tuesday, 31 July 2012 15:56:30 UTC+8, Dima Pasechnik wrote:
> On Tuesday, 31 July 2012 14:02:11 UTC+8, kfiz wrote:
>> Am Dienstag, 31. Juli 2012 07:37:42 UTC+2 schrieb Dima Pasechnik:
>>> On Tuesday, 31 July 2012 10:38:52 UTC+8, kfiz wrote:
>>>> Am Montag, 30. Juli 2012 16:25:24 UTC+2 schrieb Dima Pasechnik:
>>>>> If you look for the 1st Error in the log, you will see
>>>>> --------------------------------------------------------------------------- -------------------- >>>>> ld: warning: in build/genautomata.o, file was built for unsupported >>>>> file format which is not the architecture being linked (x86_64) >>>>> Undefined symbols: >>>>> "_main", referenced from: >>>>> start in crt1.10.6.o >>>>> ld: symbol(s) not found >>>>> collect2: ld returned 1 exit status >>>>> make[5]: *** [build/genautomata] Error 1 >>>>> make[4]: *** [all-stage1-gcc] Error 2 >>>>> make[3]: *** [stage1-bubble] Error 2 >>>>> make[2]: *** [all] Error 2
>>>>> IMHO you should set SAGE64=yes and then build. >>>>> (i.e. do >>>>> export SAGE64=yes >>>>> and then do "make build")
>>>>> Otherwise it looks like that the compiler builds 32-bit object files.
>>>>> I think that was the problem! :-) Tried to build, everything worked >>>>> fine until package 'Maxima'..weird, because except for the final 'Error' >>>>> message (check the log) everything seems to have worked fine..
>>> This log does not say at all why Maxima didn't build. >>> Could you please cut the relevant (bottom) part of install.log >>> and post it here?
>> This is the part of install.log that I didn't post before:
>> real 228m36.234s >> user 194m48.729s >> sys 22m18.712s >> Error building Sage.
>> Did you refer to this?
> I meant that maxima-5.26.0.p0.log you posted does not contain the log of > maxima build, only the fact that it ended in a failure. > In install.log there should be a part that contains a complete log of > maxima build. > It would start off like this:
> Now building Maxima; this takes a few minutes. > Since we're on MacOS X and there is a very weird > bug with buffered output while building Maxima, > you will not be able to see the output of the build > as it occurs. Don't worry, the build process does > not hang.
sorry, this is not the place... Please disregard the last message. I'll ask around how to see what can be done to see the errors...
On Tuesday, 31 July 2012 14:02:11 UTC+8, kfiz wrote:
> Am Dienstag, 31. Juli 2012 07:37:42 UTC+2 schrieb Dima Pasechnik:
>> On Tuesday, 31 July 2012 10:38:52 UTC+8, kfiz wrote:
>>> Am Montag, 30. Juli 2012 16:25:24 UTC+2 schrieb Dima Pasechnik:
>>>> If you look for the 1st Error in the log, you will see
>>>> --------------------------------------------------------------------------- -------------------- >>>> ld: warning: in build/genautomata.o, file was built for unsupported >>>> file format which is not the architecture being linked (x86_64) >>>> Undefined symbols: >>>> "_main", referenced from: >>>> start in crt1.10.6.o >>>> ld: symbol(s) not found >>>> collect2: ld returned 1 exit status >>>> make[5]: *** [build/genautomata] Error 1 >>>> make[4]: *** [all-stage1-gcc] Error 2 >>>> make[3]: *** [stage1-bubble] Error 2 >>>> make[2]: *** [all] Error 2
>>>> IMHO you should set SAGE64=yes and then build. >>>> (i.e. do >>>> export SAGE64=yes >>>> and then do "make build")
>>>> Otherwise it looks like that the compiler builds 32-bit object files.
>>>> I think that was the problem! :-) Tried to build, everything worked >>>> fine until package 'Maxima'..weird, because except for the final 'Error' >>>> message (check the log) everything seems to have worked fine..
>> This log does not say at all why Maxima didn't build. >> Could you please cut the relevant (bottom) part of install.log >> and post it here?
> This is the part of install.log that I didn't post before:
