At Thu, 14 Jun 2012 17:39:13 -0700, "David R. Morrison" <drm@...> wrote:
Subject: Re: [Fink-users] problems compiling qt4-base-mac-4.7.3-4
> On Jun 12, 2012, at 11:41 AM, Greg A. Woods wrote:
> > At Tue, 12 Jun 2012 11:35:59 -0700, Alexander Hansen <alexanderk.hansen@...> wrote:
> > Subject: Re: [Fink-users] problems compiling qt4-base-mac-4.7.3-4
> >> On 6/12/12 11:33 AM, Greg A. Woods wrote:
> >>> At Tue, 12 Jun 2012 11:28:52 -0700, Alexander Hansen
> >>> <alexanderk.hansen@...> wrote: Subject: Re: [Fink-users]
> >>> problems compiling qt4-base-mac-4.7.3-4
> >>>> Fink can prevent problems from a user's environment settings, but
> >>>> it is essentially impossible to stop the build tools from
> >>>> dragging in headers and libraries from /usr/local, since that's a
> >>>> hardcoded location in their search paths.
> >>> Then I guess that's a problem that only pkgsrc has solved! :-)
> >> On OS X? That's all I'm covering here.
> > Apparently (since it does the same tricks on all supported platforms),
> > though as yet I've personally only used pkgsrc on NetBSD.
> > At the time I wanted to add third-party open-source stuff to OS X the
> > pkgsrc versions of things I was most interested in were not as
> > up-to-date as they were in fink.
> I've never used pkgsrc so I have no idea what tricks they have, but I
> do know that the hardcoding of /usr/local into search paths which
> exists in OS X does not exist in Linux or the various BSD's.
I'm not sure exactly what you may mean here, but the problem I think
we're talking about here is primarily one where /usr/local is embedded
in the configuration scripts of various and sundry third-party software
packages -- though see below for one caveat to do with OS X cpp's
> perhaps their tricks do not work the same way on OS X&
Well, given that the user level of OS X is basically BSD, pretty much
any trick that works on any BSD will work on OS X, especially when it
comes to a build toolchain.
Consider also that OS X is just one of many a supported target platforms
The main trick used by pkgsrc is to include patches which fix any
hard-coded references to locations such as /usr/local.
To make sure the right tools are invoked in the correct manner when
building something, pkgsrc creates wrapper scripts for each major tool
chain component. The build environment is set up so that those tools
are used exclusively, and these scripts additionally do thing such as
massage command-line parameters as necessary to fix problems on specific
target platforms or with specific host compilers, etc.
There are of course special things on OS X that are different from other
platforms. For example it seems that cpp on OS X does by default look
in /usr/local/include for header files, so pkgsrc always invokes cc/gcc
and cpp with "-no-cpp-precomp -isystem /usr/include", using the latter
option to effectively put /usr/include first, though it doesn't entirely
remove /usr/local/include from the search path as I would have expected
to be done. (according to the CVS logs and the PR related to the change
which added this the reason was to err on the side of being conservative
and to not remove /usr/local/include entirely, which is rather stupid
and short-sighted in this case, but it solved the original problem from
the PR so it was considered sufficient since nobody else at the time
seemed to have the time and resources to do further testing).
Greg A. Woods
<woods@...> +1 250 762-7675 http://www.planix.com/