gv and ghostscript

[John B Brown]

On 4/28/10 9:42 PM, Ryan Schmidt wrote:
>
> On Apr 28, 2010, at 19:37, John B Brown wrote:
>
>>> That's correct. MacPorts goes to great lengths to clear the environment before running, so that the environment is consistent.
>>
>> 	Exactly what in the environment must be cleared? If I set the environment as I wish my computer to perform, what about MacPorts gives the right to remove the environment I approve for my computing?
>
> We have the right to write MacPorts however we see fit, just as any software developer can write their software however they want. In this case, we don't have the manpower to adequately maintain the ports we already have, so we certainly don't have the manpower to support users making arbitrary changes to the environment.
>

	Point taken.

	If I wish UNIX/Linux/gnu applications ported into MacOS and want to 
maintain Linux-like flexible utility I must do it myself. Or I could use 
Bootcamp to install Linux and have done with it.

>
>>>> I set 'export CC=`which gcc`' in my .bash_profile.
>>>
>>> MacPorts will clear it before running.
>>>
>>>> I've set my path so that /usr/local/bin comes before /opt/local/bin and my library load paths to look at /usr/local/lib first.
>>>
>>> This will most probably cause problems. Please unset these library load paths. (DYLD_LIBRARY_PATH, DYLD_FALLBACK_LIBRARY_PATH, LD_LIBRARY_PATH, etc.)
>>>
>>
>> 	What about the Apple version of BSD causes it to ignore the wishes of the owner and operator of the computer? In my experience with UNIX and Linux, in many flavors, I have never run into such hubris and cheek. It's so bad that there are duplicate names for obviously different C libraries delivered by Apple, one set into the Xcode system and another pair into /Developer/SDKs/MacOSX10.x.sdk/usr/lib/libc.dylib.
>
> I'm not going to respond to complaints about Mac OS X. This list is for assisting users in getting things working with MacPorts, not complaining about the operating system on which it runs.
>
>
>> 	The Xcode set of links for /usr/lib/libc.dylib goes to:
>>
>> -r-xr-xr-x  1 root  wheel  6852240 Feb 26 12:53 /usr/lib/libSystem.B.dylib*
>> lrwxr-xr-x  1 root  wheel       17 Apr 21 13:27 /usr/lib/libSystem.dylib@ ->  libSystem.B.dylib
>> lrwxr-xr-x  1 root  wheel       15 Apr 21 13:27 /usr/lib/libc.dylib@ ->  libSystem.dylib
>>
>> 	The SDK set of links, for MacOSX10.6.sdk is:
>>
>> -rwxr-xr-x  1 root  wheel  782032 Mar 11 19:08 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.B.dylib*
>> lrwxr-xr-x  1 root  wheel      17 Apr 27 13:06 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libSystem.dylib@ ->  libSystem.B.dylib
>> lrwxr-xr-x  1 root  wheel      15 Apr 27 13:06 /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libc.dylib@ ->  libSystem.dylib
>>
>> 	You will notice a MAJOR discrepance in size between both sets of library links for libc.dylib, 782032 and 6852240.
>>
>> 	I'm confused, aren't you?
>
> I don't know why there is a difference.
>

	Where might I go for an answer to why there is a difference?

>
>>>> 	That means my CC is set for gcc in /usr/local/bin which is gcc-4.5.0 which bootstrapped and installed cleanly. Doesn't macports look to /usr/local/lib first for libs as it compiles and runs?
>>>
>>> No -- not deliberately. MacPorts uses Apple's GCC compiler in /usr/bin/gcc-4.2 (on Snow Leopard, anyway) to compile (most) ports. (Individual ports can specify otherwise if needed.) But as we mentioned earlier, Apple's GCC compiler automatically looks in /usr/local and will find and use libraries and headers located there. We don't want this behavior but don't know how to stop it. Therefore we can only ask that users remove everything in /usr/local before using MacPorts in order to prevent problems.
>>>
>>
>> 	Except that all the C routines are in /usr/lib or a different sized set in SDK, and not in /usr/local/lib.
>>
>> 	I would suggest some changes in the behavior of the Apple version of gcc and the Apple version of the gnu compiling system; they should comply with normal posix systems rules. Why, pray tell, should Apple wish me to remove all my customizations, helpful to my use of my computer?
>>
>> 	That certainly ain't POSIX!
>
> Complaints and bug reports about Mac OS X should be directed to Apple, not us.
>
>
>> 	Removing any parts in these e-mails is NOT the way to keep track of problems and their solutions. Just saying!
>
> I follow standard mailing list etiquette rules and trim parts of the conversation that I am not directly replying to.
>
>
>




	Shalom,

	John B. Brown.
	[jbb at vcn.com]
	358 High Street,
	Buffalo, Wyoming
	82834

"Freedom is not worth having if it does not include
the freedom to make mistakes"  Mahatma Gandhi
"If any question why we died, tell them,
because our fathers lied."  Rudyard Kipling
"A man who does not know the truth is just an idiot
but a man who knows the truth and calls it a lie
is a crook."  Bertolt Brecht
"I wonder whether the world is being run
by smart people who are putting us on
or by imbeciles who really mean it."  Mark Twain