gv and ghostscript

John B Brown jbb at vcn.com
Wed Apr 28 17:37:44 PDT 2010


On 4/28/10 3:17 PM, Ryan Schmidt wrote:
> On Apr 28, 2010, at 13:15, John B Brown wrote:
>> On 4/28/10 10:30 AM, Rainer Müller wrote:
>>> On 27.04.2010 22:08, John B Brown wrote:
>>>>      gcc only looks in /usr/local/include if you did not configure it
>>>> with --prefix=/usr after editing the prefix entry in the configure file
>>>> to reflect that as the install tree.
>>>
>>> MacPorts uses Apple supplied compilers from Xcode. Therefore we cannot
>>> influence the configure flags at all.
>>
>> 	Does that mean my env does not control the macport compiles?
>
> 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?

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

	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?

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

>
>

	Removing any parts in these e-mails is NOT the way to keep track of 
problems and their solutions. Just saying!

>

	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


More information about the macports-users mailing list