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