[postgis-users] shp2pgsql problems on Mac OS X Leopard

[John Cartwright]

It seemed to me that William Kyngesburye's (http://www.kyngchaos.com/) 
version worked OK, but I don't know what his compilation options were.

-- john

Patrick Hartling wrote:
> Yes, that is what was happening for me. Without looking at the code, I 
> had narrowed it down to some sort of argument processing problem. On 
> my way in to the office this morning, I started wondering if it might 
> not be better to use the system-provided getopt(3) for the Mac OS X 
> case. I could not tell if that was the intention, but I will look into 
> that as soon as I can. If I come up with something other than this 
> #include removal hack, I will post a patch.
>
>  -Patrick
>
> On Dec 5, 2007, at 10:35 PM, John Cartwright wrote:
>
>> Hi Patrick,
>>
>> I think I ran into the same problem, but didn't realize what the 
>> underlying issue was.  Just found that shp2pgsql kept complaining 
>> about the inability to open valid shapefiles.
>>
>> --john
>>
>>
>> On Dec 5, 2007, at 9:32 AM, Patrick Hartling wrote:
>>
>>> I have run into a rather perplexing problem with shp2pgsql from 
>>> PostGIS 1.3.1 and 1.3.2 on Mac OS X Leopard. As far as I can tell, 
>>> the optarg and optind variables declared in ParseCmdline() of 
>>> loader/shp2pgsql.c are being linked to the globals declared in 
>>> unistd.h rather than those in loader/getopt.h. The result is that 
>>> references to these variables in ParseCmdline() give the wrong 
>>> values. Specifically, optarg is always NULL, and optind is 0 until 
>>> the loop in lines 1363 through 1377.
>>>
>>> Looking at the output from the preprocessor, optarg, optind, opterr, 
>>> and optopt are all  declared twice. The first is from unistd.h, and 
>>> the second is from PostGIS' loader/getopt.h. If I remove the 
>>> #include directive for unistd.h, shp2pgsql compiles, links, and runs 
>>> correctly, although there is a compiler warning saying that getopt() 
>>> is not declared.
>>>
>>> My guess is that there is some compiler or linker option that might 
>>> fix this behavior, but I have not been able to determine what that 
>>> might be. Removing the inclusion of unistd.h does not seem like the 
>>> best fix, but it is a workaround that gets things running for me.
>>>
>>> -Patrick
>>>
>>>
>>> -- 
>>> Patrick L. Hartling
>>> Senior Software Engineer, Priority 5
>>> http://www.priority5.com/
>>>
>>> _______________________________________________
>>> postgis-users mailing list
>>> postgis-users at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> -- 
> Patrick L. Hartling
> Senior Software Engineer, Priority 5
> http://www.priority5.com/
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>