A quick question concerning the MacPorts cmake-fu: I've noticed that you've
managed to get cmake to ignore everything installed in /usr/local . I've tried
invoking /opt/local/bin/cmake directly (= not through port) with the exact same
arguments as port uses, but then it does find libraries I
Don't forget we set our own PATH as well. Perhaps cmake actually respects it.
On July 6, 2014 11:30:07 AM EDT, René J.V. Bertin rjvber...@gmail.com wrote:
A quick question concerning the MacPorts cmake-fu: I've noticed that
you've managed to get cmake to ignore everything installed in
/usr/local
On Jul 6, 2014, at 10:30 AM, René J.V. Bertin wrote:
A quick question concerning the MacPorts cmake-fu: I've noticed that you've
managed to get cmake to ignore everything installed in /usr/local . I've
tried invoking /opt/local/bin/cmake directly (= not through port) with the
exact same
OK, here is what I propose as a relacement/extension of FAQ#defaultprefix.
* Why is /opt/local the default install location for MacPorts?
* So with macports under /opt/local I can use /usr/local freely?
I just commited this (fixing the typos.)
https://trac.macports.org/wiki/FAQ#defaultprefix
On Apr 10, 2012, at 8:00 AM, Jan Stary wrote:
OK, here is what I propose as a relacement/extension of FAQ#defaultprefix.
* Why is /opt/local the default install location for MacPorts?
* So with macports under /opt/local I can use /usr/local freely?
I just commited this (fixing the typos
I am willing to help this with ports that interest me.
Is there a way in trac to specifically select the ports
that have this problem?
not that I know of (since you don't know what is going to be
in /usr/local on any machine)
I tried searching in both the mailing list archives and trac
On Apr 10, 2012, at 11:21 AM, Jan Stary wrote:
I am willing to help this with ports that interest me.
Is there a way in trac to specifically select the ports
that have this problem?
not that I know of (since you don't know what is going to be
in /usr/local on any machine)
I tried
that got installed in /usr/local.
Yes. And if /usr/local was where macports installs its stuff,
then this would mean that the compiler picked up what macports
installed,
Yes, we know that, we wrote so a couple of times. The problem arises from all
other stuff that gets installed
If I keep MacPorts in its own prefix, it is easier to ensure that other
software on my system does not get mixed up in a build.
No, not really. You have macports stuff in its own prefix, namely,
/opt/local. However, if a given port silently picks up something
incompatible in /usr/local
On 5 Apr 2012, at 2:20am, Brandon Allbery wrote:
On Wed, Apr 4, 2012 at 19:08, Chris Jones jon...@hep.phy.cam.ac.uk wrote:
MacPorts does provide a means to set its installation root, so if *you*
really want to use /usr/local you can. Similarly you could use
/opt/I/bet/no/one/will/ever/find
I agree now that /usr/local is on fact a bad choice.
What I find cnfusing or unclear is the reasoning about it
in the the FAQ.
The most prominent reason given to me yesterday for not having
/usr/local as a default prefix was that people will stupidly
rewrite the stuff in there by blindly
On Apr 05 09:00:44, Jan Stary wrote:
However, if a given port silently picks up something
incompatible in /usr/local, if might fail and often will.
Having macports isolated in /opt/local DID NOT save you from this.
Removing /usr/local is what did.
One more point to this: what
As far as I can tell, /usr in PATH is being honored opposed to /usr/local being
picked up automatically.
Am 05.04.2012 um 10:25 schrieb Jan Stary h...@stare.cz:
On Apr 05 09:00:44, Jan Stary wrote:
However, if a given port silently picks up something
incompatible in /usr/local, if might fail
On Apr 05 10:49:01, Dominik Reichardt wrote:
As far as I can tell, /usr in PATH is being honored
opposed to /usr/local being picked up automatically.
I don't know how honored differs from being picked up,
but PATH has nothing to do with this.
Am 05.04.2012 um 10:25 schrieb Jan Stary h
Honoring the order in PATH so when /opt/local is in front of /usr, compilers
will honor that. So yes PATH has a lot to do with this. Opposed to the
/usr/local issue.
Check your attitude please
Am 05.04.2012 um 10:59 schrieb Jan Stary h...@stare.cz:
On Apr 05 10:49:01, Dominik Reichardt wrote
The thread has pointed out that there would not be an issue if that were the
case: it appears Gnu toolchain puts /usr/local first.
Dominik Reichardt domi...@gmail.com wrote:
Honoring the order in PATH so when /opt/local is in front of /usr,
compilers will honor that. So yes PATH has a lot to do
with this. Opposed to the /usr/local issue.
Check your attitude please
Check what PATH is.
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
On Apr 05 04:13:44, Jeremy Lavergne wrote:
The thread has pointed out that there would not be an issue
if that were the case: it appears Gnu toolchain puts /usr/local first.
Even if the build tools put /usr/local before /usr,
the example still stands: I don't have /usr/local at all.
I have
So /usr/local is kept hostage by crap GNU tools.
I do note that most Linux distros manage to convince even GNU crapware to
install somewhere outside /usr/local. I'd be surprised if they permitted their
builds to get distracted by stuff in /usr/local. But then they tend (Gentoo
excepted
and configure tweaks
to ensure that the stuff they use is installed in /usr/local
from OpenBSD packages,
That's not done by configure tweaks
- checksums are kept for the installed files.
___
macports-users mailing list
macports-users
On 2012-04-05, Jan Stary h...@stare.cz wrote:
(The XXX is where my English fails me. Could a native speaker
put the right verb in please that seems to slip my mind?)
[...]
While this could be XXXed off as the user's own error, it is a fact that
written off as
chalked up to
dismissed as
--
On Apr 05 08:47:47, Arno Hautala wrote:
On 2012-04-05, Jan Stary h...@stare.cz wrote:
(The XXX is where my English fails me. Could a native speaker
put the right verb in please that seems to slip my mind?)
[...]
While this could be XXXed off as the user's own error, it is a fact
to declare this, so
you make sure it doesn't happen by removing /usr/local altgether,
or making the user remove his /usr/local, which you will agree is
a pretty extreme measure on a UNIX system.
Simply put, MacPorts does not SUPPORT /usr/local in the sense that if you ask
for help from MacPorts we
in ports
I maintain). Not all ports provide a way to declare this, so
you make sure it doesn't happen by removing /usr/local altgether,
or making the user remove his /usr/local, which you will agree is
a pretty extreme measure on a UNIX system.
Simply put, MacPorts does not SUPPORT /usr/local
On Apr 5, 2012, at 11:44 AM, Jan Stary wrote:
However, I believe that if a port chokes on picking up
some unintended dependency it found in /usr/local
(or anywhere, for that matter), it is that port's
problem: I don't think it's /usr/local's fault being
there - I think it's the port's defect
to be in /usr/local on
any machine)
the /real/ fix would be to either:
- change build behavior for cc/ld/cpp (which may be possible, but no one has
tried to do it as far as I know) -nostdinc (or equivalent) plus adding back
the appropriate search paths for every supported platform
- change
On 05/04/2012, at 10:00 PM, macports-users-requ...@lists.macosforge.org wrote:
oh... I didn't know that. I just took a look in my /usr/local, and found a
whole bunch of stuff for texlive, and then various programs that I remember
installing.
is there a recommended place for me to put
On Apr 4, 2012, at 00:44, Jan Stary wrote:
On Apr 03 17:54:05, saiwingy wrote:
Since MacPorts is not compatible with /usr/local, every time I install/update
ports I had to
sudo mv /usr/local /usr/local.bak
Why would you move /usr/local?
Macports live under /opt/local by default
On Apr 3, 2012, at 8:40 PM, Ryan Schmidt wrote:
On Apr 3, 2012, at 19:54, saiwingy wrote:
Since MacPorts is not compatible with /usr/local, every time I install/update
ports I had to
sudo mv /usr/local /usr/local.bak
and then after I am done building macports stuff I would move it back
Since MacPorts is not compatible with /usr/local, every time I
install/update
ports I had to
sudo mv /usr/local /usr/local.bak
Why would you move /usr/local?
Macports live under /opt/local by default
and have nothing to do with /usr/local.
Having things installed in /usr
Hi,
I don't install things there, but there are things in there (mostly from Mac
OS) that I'd like to keep and use.
I might be wrong but I understand OS X itself does not put anything in
/usr/local. Anything you might have there has probably come from other
third party applications you
Hi,
I thought the whole reason for living under /opt/local was *not* to
interfere with /usr/local. How exactly does having /usr/local interfere?
Things from macports silently picking up things from /usr/local?
Is that the problem?
The issue is some packages have hard coded dependencies
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2012 10:17, Chris Jones wrote:
I thought the whole reason for living under /opt/local was *not*
to interfere with /usr/local. How exactly does having /usr/local
interfere? Things from macports silently picking up things from
/usr/local
Le 04.04.12 08:38, Ryan Schmidt a écrit :
Hello,
The macport home directory is opt/local not usr/local
Best regards
mparchet
On Apr 4, 2012, at 00:44, Jan Stary wrote:
On Apr 03 17:54:05, saiwingy wrote:
Since MacPorts is not compatible with /usr/local, every time I install/update
ports I
On Wed, Apr 4, 2012 at 03:45, Saiwing Yeung saiw...@berkeley.edu wrote:
On Apr 3, 2012, at 8:40 PM, Ryan Schmidt wrote:
On Apr 3, 2012, at 19:54, saiwingy wrote:
Since MacPorts is not compatible with /usr/local, every time I
install/update
We don't install things in /usr/local. Why do
On Apr 04 10:17:23, Chris Jones wrote:
Hi,
I thought the whole reason for living under /opt/local was *not* to
interfere with /usr/local. How exactly does having /usr/local interfere?
Things from macports silently picking up things from /usr/local?
Is that the problem?
The issue is some
, but not all do.
Isn't that a task of the port maintainer then
to patch such a software so that any interference
with /usr/local can be avoided?
the problem lies with the apple-supplied complier toolchain, there is no 'good'
solution to the issue.
(there are several things that might work, or could
I just find it quite extreme to expect the user to not have
/usr/local around. The reason macports uses /opt/local (if I am
not wrong) is that macports realizes that people *do* have
/usr/local around.
I, personally, have had /usr/local around for forever. The issue is that if
you
OK, I can understand that. Did I really miss this bit
in the documentation? Can someone point me please?
I believe it should be clearly stated in the Guide.
It is not in the Guide, however the FAQ wiki page references it:
https://trac.macports.org/wiki/FAQ#defaultprefix
smime.p7s
://trac.macports.org/wiki/FAQ#defaultprefix
Yes, that's what I have read. But that just says why macports
uses /opt/local: because it cannot use /usr/local, for the reasons listed.
This here is something *different*: namely, that
(1) There might still be problems if the user has /usr/local around.
(2) So the user
Yes, that's what I have read. But that just says why macports
uses /opt/local: because it cannot use /usr/local, for the reasons listed.
This here is something *different*: namely, that
(1) There might still be problems if the user has /usr/local around.
• Some software
On Apr 04 10:34:48, Jeremy Lavergne wrote:
Yes, that's what I have read. But that just says why macports
uses /opt/local: because it cannot use /usr/local, for the reasons listed.
This here is something *different*: namely, that
(1) There might still be problems if the user has /usr
oh... I didn't know that. I just took a look in my /usr/local, and found a
whole bunch of stuff for texlive, and then various programs that I remember
installing.
is there a recommended place for me to put these programs?
On Apr 4, 2012, at 2:12 AM, Chris Jones wrote:
Hi,
I don't
On Apr 4, 2012, at 10:55, Jan Stary wrote:
In fact, I believe it is a good candidate for a FAQ immediately
following https://trac.macports.org/wiki/FAQ#defaultprefix:
Q: So given that macports uses /opt/local as its prefix,
I can use /usr/local freely without worying about interference
On Apr 4, 2012, at 11:16, Saiwing Yeung wrote:
oh... I didn't know that. I just took a look in my /usr/local, and found a
whole bunch of stuff for texlive, and then various programs that I remember
installing.
is there a recommended place for me to put these programs?
Any other place
On Apr 4, 2012, at 9:55 AM, Jan Stary wrote:
Q: So given that macports uses /opt/local as its prefix,
I can use /usr/local freely without worying about interference?
A: No, not really. (etc)
I'd really like to see an expansion of that etc.
I use Linux extensively for my servers and Macs
I use Linux extensively for my servers and Macs when I'm trying to be a
human. /usr/local has been around for quite a while in the *nix world (it's
even in the default $PATH), and I use it a little on the Macs. I can't think
of what the problem is -- (seems to) work fine here :-)
I don't
On Apr 4, 2012, at 11:20, Glenn English wrote:
On Apr 4, 2012, at 9:55 AM, Jan Stary wrote:
Q: So given that macports uses /opt/local as its prefix,
I can use /usr/local freely without worying about interference?
A: No, not really. (etc)
I'd really like to see an expansion
On Apr 4, 2012, at 10:26 AM, Jeremy Lavergne wrote:
I don't see /usr/local in my system's default for $PATH, either on 10.6 or
10.7.
Sorry. Maybe I should have said, the default *nix $PATH. I don't know about
others.
OTOH, here's my user $PATH on 10.7.3: /usr/local/bin:/usr/bin:/bin:/usr
On Apr 4, 2012, at 9:19 AM, Ryan Schmidt wrote:
On Apr 4, 2012, at 11:16, Saiwing Yeung wrote:
oh... I didn't know that. I just took a look in my /usr/local, and found a
whole bunch of stuff for texlive, and then various programs that I remember
installing.
is there a recommended place
On 04/04/2012 06:26 PM, Jeremy Lavergne wrote:
I use Linux extensively for my servers and Macs when I'm trying to be a
human. /usr/local has been around for quite a while in the *nix world (it's
even in the default $PATH), and I use it a little on the Macs. I can't think
of what the problem
On Apr 4, 2012, at 10:27 AM, Ryan Schmidt wrote:
Because /usr/local is searched by default by the compiler and we do not know
how to turn that off, MacPorts ports might try to link with libraries you've
installed in /usr/local.
Ah! Thank you; that makes sense. I'll try to stay away from
On Apr 4, 2012, at 12:42, Glenn English wrote:
On Apr 4, 2012, at 10:27 AM, Ryan Schmidt wrote:
Because /usr/local is searched by default by the compiler and we do not know
how to turn that off, MacPorts ports might try to link with libraries you've
installed in /usr/local.
Ah
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2012 18:30, Saiwing Yeung wrote:
On Apr 4, 2012, at 9:19 AM, Ryan Schmidt wrote:
On Apr 4, 2012, at 11:16, Saiwing Yeung wrote:
oh... I didn't know that. I just took a look in my /usr/local, and found a
whole bunch of stuff for texlive
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2012 19:40, Phil Dobbin wrote:
On 04/04/2012 18:30, Saiwing Yeung wrote:
On Apr 4, 2012, at 9:19 AM, Ryan Schmidt wrote:
On Apr 4, 2012, at 11:16, Saiwing Yeung wrote:
oh... I didn't know that. I just took a look in my
/usr/local
I might not be opposed to MacPorts printing a warning if anything is found in
/usr/local/{bin,etc,include,lib,libexec,man,sbin,share,var}. But I would
probably only want to print that if a port actually failed to build.
It sounds very reasonable to check if there's anything in /usr/local
The more I think about it, the more I tend to this conclusion:
Using /opt/local as the default prefix is an attempt
to save the user from himself, which is pointless.
Any other benefits it has would also be present
if the default prefix was /usr/local.
Please bare with me and wait
/usr/local is not a viable choice because some software
(especially auto* tools from Gnu) look in /usr/local
as a default location, which means MacPorts can't be
easily isolated when needed.
I want to kindly ask the person who wrote this to elaborate,
and be as specific as can be: what
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2012 22:01, Jan Stary wrote:
[...]
You'd probably have to create the directory in /Users/yourname
Huh? That's my $HOME, which obviously exists already.
I was referring to the /bin directory not $HOME
`PATH=$PATH:$HOME/bin`
That
`PATH=$PATH:$HOME/bin`
That puts it last in the path, which is probably
not what you intended.
Your logic there defeats me...
Just standard concatenation: it was appended at the end.
This doesn't much matter though, since the original thread has nothing to do
with $PATH.
smime.p7s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2012 22:15, Jeremy Lavergne wrote:
`PATH=$PATH:$HOME/bin`
That puts it last in the path, which is probably not what you
intended.
Your logic there defeats me...
Just standard concatenation: it was appended at the end.
This
On Apr 04 16:05:27, Jeremy Lavergne wrote:
/usr/local is not a viable choice because some software
(especially auto* tools from Gnu) look in /usr/local
as a default location, which means MacPorts can't be
easily isolated when needed.
I want to kindly ask the person who wrote
. It's not feasible
to expect that every package is available in macports. Whether you like it or
not, sometimes people will have to install something that hasn't been ported.
If they want to install it in a system-wide directory, so that it's easily used
by many users, /usr/local is the obvious
You keep saying that: the software that magically finds its way to
/usr/local. What do you even mean by that? The user installed it
there; that's about the only way something gets into /usr/local.
The user is typically unaware of where packaged software is installed. You can
look at our
On 04.04.2012, at 23:20, Jan Stary wrote:
On Apr 04 16:05:27, Jeremy Lavergne wrote:
/usr/local is not a viable choice because some software
(especially auto* tools from Gnu) look in /usr/local
as a default location, which means MacPorts can't be
easily isolated when needed.
I want
(as above).
/usr/local is not a viable choice because some software
(especially auto* tools from Gnu) look in /usr/local
as a default location, which means MacPorts can't be
easily isolated when needed.
I want to kindly ask the person who wrote this to elaborate,
and be as specific as can be: what
On Apr 4, 2012, at 5:01 PM, Jan Stary wrote:
Using /opt/local as the default prefix is an attempt
to save the user from himself,
[snip]
There are lots of good reasons to use a $prefix other than /usr/local
If you care, you can probably find all of the reasoning in the mailing list
archives
On Apr 04 23:32:26, Dominik Reichardt wrote:
On 04.04.2012, at 23:20, Jan Stary wrote:
On Apr 04 16:05:27, Jeremy Lavergne wrote:
/usr/local is not a viable choice because some software
(especially auto* tools from Gnu) look in /usr/local
as a default location, which means MacPorts
On 04.04.2012, at 23:48, Jan Stary wrote:
On Apr 04 23:32:26, Dominik Reichardt wrote:
On 04.04.2012, at 23:20, Jan Stary wrote:
On Apr 04 16:05:27, Jeremy Lavergne wrote:
/usr/local is not a viable choice because some software
(especially auto* tools from Gnu) look in /usr/local
/local is not a viable choice because some software
(especially auto* tools from Gnu) look in /usr/local
as a default location, which means MacPorts can't be
easily isolated when needed.
I want to kindly ask the person who wrote this to elaborate,
and be as specific as can be: what exactly
just pointing out that you installed it there yourself,
and if it broke things, that's not a failure of the packaging system.
Of course MacPorts WILL install libpng in /opt/local.
But when the port that requires libpng is then built the compiler may chose
the libpng that got installed in /usr/local
chose
the libpng that got installed in /usr/local.
Yes. And if /usr/local was where macports installs its stuff,
then this would mean that the compiler picked up what macports
installed, by default.
When MacPorts is prefixed in /opt/local and some process installs files to
/usr/local
installer program, and magic happened.
And how do we stop the user from rewriting something that is already there?
We don't, and we can't. It's the user's responsibility to not be an idiot
and rewrite something he has installed himself before.
That is a reason why we shouldn't use /usr/local
Hi,
On Apr 04 11:26:14, Jeremy Lavergne wrote:
/usr/local is horrible because it takes precedence
over everything else on your system
Yes, it takes precedence. That's the point: to have a place where
things are supposed to be installed. Why does it make /usr/local horrible?
How would
Hi,
Yes, I understand this. What I don't understand is how
having /opt/local as a prefix makes this better than
having /usr/local (or whatever else).
Its just statistics. /usr/local is a relatively common place for third party
applications to dump stuff, so usin git you are likely
This ksh command line:
for y in ${PATH//:/ } ; do for x in $y/* ; do if [[ -r $x ]] ; then strings
$x | grep -sq /usr/local print `basename $x` ; fi ; done ; done | sort -u
| wc -l
produces 123 hits on my system. The same command, but using /opt/local,
produces 834. Only 28 commands
gather they're learning the
hard way the lesson you seem to be going out of your way to not figure out).
/usr/local is not a viable choice because some software
(especially auto* tools from Gnu) look in /usr/local
as a default location, which means MacPorts can't be
easily isolated
On Wed, Apr 4, 2012 at 19:08, Chris Jones jon...@hep.phy.cam.ac.uk wrote:
MacPorts does provide a means to set its installation root, so if *you*
really want to use /usr/local you can. Similarly you could use
/opt/I/bet/no/one/will/ever/find/this/ to be completely safe …
Actually, I think
a particular dependency is found to be
used, a problem if there is more than one version of a dependency
active at a time for the different installed port. I have actually had
this happen a couple of times when trying to install non-MacPorts
third party software into usr/local and having
Since MacPorts is not compatible with /usr/local, every time I install/update
ports I had to
sudo mv /usr/local /usr/local.bak
and then after I am done building macports stuff I would move it back. This
works fine but is kind of cumbersome and sometimes the moved /usr/local
directory triggers
Since MacPorts is not compatible with /usr/local, every time I install/update
ports I had to
sudo mv /usr/local /usr/local.bak
and then after I am done building macports stuff I would move it back. This
works fine but is kind of cumbersome and sometimes the moved /usr/local
directory
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2012 01:54, saiwingy wrote:
Since MacPorts is not compatible with /usr/local, every time I install/update
ports I had to
sudo mv /usr/local /usr/local.bak
and then after I am done building macports stuff I would move it back
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 04/04/2012 01:57, Jeremy Lavergne wrote:
Since MacPorts is not compatible with /usr/local, every time I install/update
ports I had to
sudo mv /usr/local /usr/local.bak
and then after I am done building macports stuff I would move it back
On Apr 3, 2012, at 19:54, saiwingy wrote:
Since MacPorts is not compatible with /usr/local, every time I install/update
ports I had to
sudo mv /usr/local /usr/local.bak
and then after I am done building macports stuff I would move it back. This
works fine but is kind of cumbersome
On Apr 03 17:54:05, saiwingy wrote:
Since MacPorts is not compatible with /usr/local, every time I install/update
ports I had to
sudo mv /usr/local /usr/local.bak
Why would you move /usr/local?
Macports live under /opt/local by default
and have nothing to do with /usr/local
I see
f...@mac:~:124 $ /usr/bin/make -dp | grep INCLUDE
make: *** No targets specified and no makefile found. Stop.
.INCLUDE_DIRS = /usr/include /usr/local/include /usr/include
The deal is - if /usr/local/include *exists* it will be included
mac:~ root# echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin
and no makefile found. Stop.
.INCLUDE_DIRS = /usr/include /usr/local/include /usr/include
The deal is - if /usr/local/include *exists* it will be included
mac:~ root# echo $PATH
/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin
mac:~ root# /usr/bin/make -dp | grep INCLUDE
make
On 2009-10-23 11:07, Bayard Bell wrote:
Did a bit more digging. The problem looks to be with Apple's build of
make. Extracted from make -dp output:
# default
.INCLUDE_DIRS = /usr/include /usr/local/include /usr/include
From the make manual:
.INCLUDE_DIRS
Expands to a list of directories
to be with Apple's build of
make. Extracted from make -dp output:
# default
.INCLUDE_DIRS = /usr/include /usr/local/include /usr/include
From the make manual:
.INCLUDE_DIRS
Expands to a list of directories that make searches for included
makefiles
This does not affect the C preprocessor at all
:
http://www.opensource.apple.com/source/gcc/gcc-5646/gcc/configure
and defaults to /usr/local.
- Josh
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (Darwin)
iEYEARECAAYFAkrh0ssACgkQcZQHT1XL9xlxnwCfQEwPSyTRhhVazwN40/F3Gtt+
fwkAniIFKyKfBccYhLBfPiWoSMK+qtUy
=Ev35
-END PGP SIGNATURE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Did a bit more digging. The problem looks to be with Apple's build of
make. Extracted from make -dp output:
# default
.INCLUDE_DIRS = /usr/include /usr/local/include /usr/include
Filing bug report now. Again dtruss gives me a clue to put
On Oct 22, 2009, at 19:07, Bayard Bell wrote:
Did a bit more digging. The problem looks to be with Apple's build
of make. Extracted from make -dp output:
# default
.INCLUDE_DIRS = /usr/include /usr/local/include /usr/include
Filing bug report now.
I guess they've fixed that already
On 2009-10-17 11:57, Bayard Bell wrote:
I've been looking through tickets, trying to figure out what's going
wrong. There's an open ticket for this, 19918. As far as I can see, the
immediate problem occurs when you've got db.h in /usr/local/include.
Renaming the file certainly fixes
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've been looking through tickets, trying to figure out what's going
wrong. There's an open ticket for this, 19918. As far as I can see,
the immediate problem occurs when you've got db.h in /usr/local/
include. Renaming the file certainly fixes
On 30/09/2009, at 3:21 PM, Ryan Schmidt wrote:
On Sep 29, 2009, at 23:59, Peter B. West wrote:
Following some recent messages about problems with software in /usr/
local. I had a look. I had quite a bit of stuff in there.
hg
mysql
tcl/tk
gfortran
gcc in libexec
wireshark
Note it is only
Following some recent messages about problems with software in /usr/
local. I had a look. I had quite a bit of stuff in there.
hg
mysql
tcl/tk
gfortran
gcc in libexec
wireshark
I removed the mysql, and installed mysql5-devel and mysql5-server-
devel from MacPorts.
I removed wireshark from
thanks for the help.
I made a symlinked pointing to /usr/local and installed to the link.
MacPorts ended up in /usr/local and able to see all of my old ports.
And yes, after I uninstalled the old ports I uninstalled MacPorts and
reinstalled to /opt/local.
thanks again,
Paul
Ryan Schmidt
Hello,
Way back when, I installed MacPorts in /usr/local. I upgraded to Snow
Leopard and have attempted to get MacPorts 1.8 to install there to no
avail. I know that Snow Leopard messes with /usr/local permissions.
I've tried all kinds of things to convince it to go there, but it won't
I think the default is usually the default is /opt/local with usual a
symlink to /usr/local/
On Sep 24, 2009, at 12:51 PM, Paul T Baker wrote:
Hello,
Way back when, I installed MacPorts in /usr/local. I upgraded to
Snow Leopard and have attempted to get MacPorts 1.8 to install
On Sep 24, 2009, at 11:53, Ben Greenfield wrote:
On Sep 24, 2009, at 12:51 PM, Paul T Baker wrote:
Way back when, I installed MacPorts in /usr/local. I upgraded to
Snow Leopard and have attempted to get MacPorts 1.8 to install
there to no avail. I know that Snow Leopard messes with /usr
1 - 100 of 111 matches
Mail list logo
