vecLibFort @0.4.1 fails to build on OS X 10.5.8, PPC 7450

[zzanderr]

Several days ago, Octave was updated and I decided it was an optimal time to do a fresh install, as I needed to change a few variants and wanted to make absolutely sure there were no linking problems with components that are optional dependencies of Octave. I had recently noticed vecLibFort and decided to try it out--I am tired of troubleshooting Atlas

Alas, it would not build. I checked the current Portfile of vecLibFort to make absolutely sure that it had not been revised in the past couple of days since I tried to install it, and found that it is as it was. Perhaps I did something incorrectly, or have something installed that that is interfering, but the vecLibFort has no variants, and I do not use the /usr/share/ directory for anything--it is empty; nor do I have a Fink/Homebrew package manager.

Thus, the problem seems to be that I have

1. installed some MacPorts package that caused the failure,
2. used the wrong compiler, or
3. vecLibFort does not run out-of-the-box on a 10.5.8, PPC 7450

By the way, after some research, I have fallen under the impression that it is Apple's 64-bit Accelerate that has bugs, and the old 32-bit version is OK. Am I correct?

I am attaching the log for the build. Hope this helps prevent any future problems.

[zzanderr]

vecFortBuild failure log

[zzanderr]

Hello...Hello...Hello... Is there any body in there? Just nod if you can hear me. Is there anyone at home?

Pink Floyd

[seanfarley (Sean Farley)]

Being on PPC makes it hard for us to debug since that processor has long since seen its day. In fact, the entire commit history of vecLibFort took place after the PPC was deprecated, so having those missing symbols probably means you need a newer OS (that would ship a new accelerate framework).

If getting this to work on the PPC is important to you, then I would suggest trying to get the project to help you build on the PPC first. Then after that works, we could support it in MacPorts.

[zzanderr]

Probably getting help from the vecLibFort project would make things easier in the long run than trying to get ATLAS to work again and again after each of its upgrades. However, I have managed to get Octave (and qrupdate) to run with the 32-bit Accelerate (using dotwrp as the wrapper) without having seen any problem yet. I ask whether the bugs in Apple's Accelerate are in the 32-bit version, because, if they are, I might try a bit harder to fix ATLAS linkage, as I have been able to get ATLAS to build using GCC46; but that step will require rebuilding all other packages that have Fortran libraries, from fftw-3 on down to Octave, and probably any of their other dependents--currently all built with GCC48. My impression is that the problems are with the 64-bit Accelerate, although I am uncomfortably far from certain.

If 32-bit Accelerate actually does work, then I should continue to use it, yet the updates for the packages that have now become dependent on vecLibFort can only be made if I already have vecLibFort, unless I resort to editing their Portfiles, and/or using the "-n" option to port. Is it possible to create +dotwrp and +vecLibFort variants for Octave, qrupdate and other packages that need Fortran wrappers--presuming, that is, that 32-bit Accelerate is OK?

At any rate, if you should happen to know whether 32-bit Accelerate (v1.4.2) is buggy, it would save me much effort taken in the wrong direction...

[tenomoto (Takeshi Enomoto)]

Sorry for slow response. Thank you for your patience; this is a volunteer work. I made a patch to the source to enable builds on Leopard. In fact I need ncarg and octave on a big-endian machine (Power Mac G5)! I created a pull request to the developer. Done in r126029.

[zzanderr]

Thanks, I appreciate your help! I figured you were busy, and I certainly understand.

I'll try it out as soon as I can. All my ports that use Fortran are built with gcc48, but I have not been able to build ATLAS with gcc48 since gcc48's last upgrade. I managed to build ATLAS using gcc46 and an older Portfile from the repository, but have been putting off the arduous task of rebuilding the whole dependency chain through Octave and beyond. So you have saved me quite a bit of unnecessary work! I'll let you know how it turns out.

Thanks again!

[tenomoto (Takeshi Enomoto)]

I found that there is still a problem. It seems that I introduced the problem I fixed 4 years ago (#21797). I'm interacting with the developer to see if we can fix. Otherwise I'll resurrect dotwrp (Fortran) for PPC.

[zzanderr]

OK. I was just about to update, so thanks for the info. I will watch the portfile versioning to see if you get the developers to fix it. Good luck!

[tenomoto (Takeshi Enomoto)]

Returning structs by value is architecture dependent and sometimes problematic. It turned out that the use of C99 complex types can fix the problem (cf ​issue 6 on github and my blog ​post). Committed in r126238. I was able to build octave +accelerate on ppc.

[zzanderr]

Great! Thanks for all the hard work. I will try it out today or tomorrow.

[zzanderr]

Well, it installed and Octave seems to work as it should.

Again, many thanks!

[zzanderr]

(Octave with Accelerate, that is)

[cooljeanius (Eric Gallager)]

Cc Me!