[GRASSLIST:4022] Re: problem compiling new 5.7 source......more problems and info

[Andrew]

Paul Kelly wrote:

> On Fri, 23 Jul 2004, Andrew wrote:
>
> [...]
>
>> The first error/failure involving nad2bin.c (as quoted below) was 
>> corrected by changing the include line from
>> #include <projects.h>
>> to
>> #include "/usr/local/mapserve/include/projects.h"
>>
>> which I don't think should be necessary based upon the configure 
>> command.
>
>
> The general idea is that nad2bin.c should not need to be compiled (it 
> is an internal PROJ program and requires projects.h which is really an 
> internal PROJ header); the version of nad2bin on the system that is 
> installed with PROJ.4 should be used here. But the current state of 
> lib/proj/Makefile doesn't reflect this.
>
>>
>> The compile then continued until it reached 'g.proj' under the 
>> 'general' directory. There were duplicate definitions due to the line
>> #include  <cpl_csv.h>
>> deletion of this line allowed the compile to continue until
>
>
> What do you mean by duplicate definitions? What was the error? 
> cpl_csv.h guards against multiple inclusions so I can't see this being 
> a problem. It is included because of the call to SetCSVFilenameHook().
>
> Paul
>
I mean that after "fixing" the nad2bin problem (if that's what modifying 
the include accomplished) my compile failed until/unless I removed the 
line in g.proj/main.c that includes cpl_csv.h  The failure was indicated 
by a fatal error message that listed a dozen or so already defined 
quantities attributed to cpl_csv.h
I didn't save the log, since the elimination of this file resulted in a 
continued compilation. I do not/did not include any CSV headers or 
references explicitly, i.e. I don't think I compiled against a prior 
version, though I did have grass 5.30 installed (I renamed its directory 
structure before compiling so it was not in the system executable or 
library path). This is all I know about the error and its "fix". I 
thought it might be significant to report it in case someone else ends 
up in the same situation...it seemed that if the make doesn't use the 
paths as set in the configure command then there might be a problem 
under my architecture and system version. I could recompile from scratch 
and reproduce all the errors if someone wants them.