From: Greg A. W. <wo...@pl...> - 2012-06-15 19:19:58
|
At Thu, 14 Jun 2012 17:39:13 -0700, "David R. Morrison" <dr...@fi...> 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 <ale...@gm...> 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 > >>> <ale...@gm...> 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 default configuration. > So > 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 for pkgsrc. 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 Planix, Inc. <wo...@pl...> +1 250 762-7675 http://www.planix.com/ |