On Sep 9, 2008, at 5:25 AM, Peter W. Draper wrote:

> On Mon, 8 Sep 2008, Tim Jenness wrote:
>
>> - I seem to need to remove the -notstdlib from the generated  
>> libtool for building shared fortran libraries (the archive_cmd  
>> section)
>
> Presumably because the runtime libraries where not in the standard  
> directories?
>

possibly. It may be something with my install since I didn't want to  
copy all of the gfortran libraries into /usr/local - just the fortran  
run time.


>> - cfitsio did not seem to pick up LDFLAGS so built a 32-bit  
>> library. (manual intervention)
>
> OK, I seem to have broken that when allowing the shareable library  
> to be built. Added some probably fixes.
>

thanks

>> - gfortran seems to respect the convention that
>>
>> #include <config.h>
>>
>> refers to a system include location and
>>
>> #include "config.h"
>>
>> refers to a user location respecting -I. This pretty much breaks  
>> all fortran that uses .F (eg gns, gks). The fix is simple but it's  
>> a bit odd (clearly gcc treats -I as working with <>). Changing  
>> every .F to use "config.h" seems to work but I wonder what the  
>> feeling is regarding me committing these changes. I imagine Norman  
>> or Peter may have opinions.
>
> Well it's new. Previously gfortran didn't do this. I've had a look  
> at the bug database and mailing lists and it's not clear to me if  
> this is intentional or not, but there have been some developments to  
> way that the preprocessor is invoked (previously it used "cpp - 
> traditional-cpp", but now there's an attempt to allow more  
> flexibility in the tokens handling, being mindful that Fortran and C  
> do not have the same lexical structure).
>
> Personally I'd say just commit the fixes. Looking in the local  
> directory first is what's intended.
>

ok

>> - vtk has trouble building cmcurl because it insists on adding -Wno- 
>> long-double for Apple but that is not supported by the Apple  
>> compilers. Odd. It may just be that our cmake is out of date.
>
> Yes, looks like a bug:
>
>   http://www.vtk.org/Bug/view.php?id=7357
>
> so we can either install the curl binary, live with this, or try an  
> update from the CMake CVS.
>

or commit the 5 line patch that got it working. Which I've now done.

>> - JPL does not build because it does not seem to initialise the  
>> EPCOMM common block. There is
>>
>>  EXTERNAL COMDAT
>>
>> but gfortran doesn't seem to include a real symbol COMDAT in the  
>> link table. It's a DATA segment (on linux g95 gives a "T" with nm,  
>> "D" on OSX gfortran). I have to explicitly add a dummy subroutine  
>> to comdat.f and explicitly call it from ephopn.f to force the  
>> linker to work.... (I think this happened on g95 a couple of years  
>> ago but was fixed)
>
> Don't know what to make of that.
>

This was fixed in April 2006 for g95. Specifically g77 and g95 include  
a reference to a subroutine that does nothing so that the linker will  
link the block data module.

http://gcc.gnu.org/onlinedocs/gcc-3.3.6/g77/Block-Data-and-Libraries.html

so it's a bug in gfortran. Not sure if this is a new bug or an old bug  
with gfortran.

With the g77 test program on that web page, I get this with gfortran  
4.1.2:

% nm xxx.o
0000000000000000 B foo_
0000000000000000 D vars_

with g95 I get:

0000000000000000 T foo_
0000000000000000 D vars_

Peter: can you report this bug to gfortran if it isn't already in?

>> - itk does not build properly. It seems to detect the Tk framework  
>> and does not pick up /star. Oddly libitcl built fine.
>
> Can I have a look at that somewhere?
>

I can give you an account on the new Mac at JAC.


>> - The dependencies seem to be broken because it does not try to  
>> build vtk before building gaia.
>
> That's new. They were OK not long ago (except for the mers issues).
>

Yes. It was my recent patch. For some reason vtk was dropped off the  
list.

Checking out vtk from scratch got it building in 64-bit mode but it is  
still failing in the ftbase.c. Continuing to look.

-- 
Tim Jenness
Joint Astronomy Centre