On Mar 13, 2008, at 10:27 PM, Alexander K. Hansen wrote:
> On Thursday 13 March 2008 08:12:14 pm Ben Abbott wrote:
>> On Mar 13, 2008, at 9:17 AM, Alexander Hansen wrote:
>>> Ben Abbott wrote:
>>>> The current octave.info files still points to gcc4.2 library.
>>>> Should this not be updated to respect gcc4.3?
>>>>
>>>> ConfigureParams: FLIBS=%p/lib/gcc4.2/lib/libgfortran.dylib F77=%p/
>>>> bin/gfortran --infodir='${prefix}/share/info' --mandir='${prefix}/
>>>> share/man' --libexecdir='${prefix}/lib' -enable-shared -enable-dl
>>>> --
>>>> disable-static --without-mpi --with-hdf5 --with-fftw
>>>>
>>>> I expect there are similar occurances in other packages as well.
>>>>
>>>> Ben
>>>
>>> It was updated without anybody informing me, but yes, that update
>>> should be made.
>>
>> I notice gcc43 includes a conflict with gcc42
>>
>> Conflicts: gcc4, gcc42
>>
>> I've been using a local octave.info file to build a bleeding-edge
>> version of octave. Recently, I've been having problems that may be
>> related to gfortran 4.2, I so I thought I'd try 4.3.
>>
>> Unfortunately, modifying the .info files for packages that octave
>> depends on wasn't so simple (atlas for example).
>>
>> So if I install gcc43, I'll not be able to build anything that
>> depends
>> upon gcc42, unless I modifiy each respective .info file:-(
>>
>> What is the usual procedure when upgrading between gccX.Y to gccX.Z?
>>
>> Ben
>
> You're kind of on your own for local stuff.
Sure, no problem there.
> For most non-compiler things, any
> dependency on gccX.Y is build-time, so it's not such a huge deal to
> swap back
> and forth.
The reason I asked, is that I've been warned that gfortran was
recenlty modified and that I might encounter problems if I mix
compilers.
The comment made is below (link also provided).
The ZDOTC function is a Fortran function returning double complex.
There was a recent gfortran change in calling conventions for
functions (not subroutines) that return complex variables. I suspect
you are mixing the two methods here, compiling zqrqhv with a compiler
that implements one of the methods, and using a version of ATLAS that
was compiled to use the other.
http://www.nabble.com/failed-build-with-current-mercurial-sources-to15896284.html
Unfortunately, I believe I have dependencies compiled with gcc older
than 4.2, and unless I'm mistaken XCode's lapack/blas also qualify.
Any thoughts on how I might force rebuilds of all packages so that
they are all compiled with gcc 4.2?
Any idea which version of gcc included this change to gfortran?
Ben
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Fink-users mailing list
Fink-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/fink-users
