gv and ghostscript

[Ryan Schmidt]

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.


>>> 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.


>>> 	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.