Opened 13 years ago
Closed 12 years ago
#30395 closed defect (duplicate)
libtool requires me to remove /usr/bin/gfortran
| Reported by: | f.calboli@… | Owned by: | ryandesign (Ryan Carsten Schmidt) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.0.0 |
| Keywords: | gfortran | Cc: | drkp (Dan Ports) |
| Port: | libtool |
Description
libtool does not build if I have a /usr/bin/gfortran executable. Renaming it fixes the problem, nevertheless it is unacceptable that MacPorts would cause conflicts with software that is not in /opt/local. I do have gfortran in /usr/bin for a reason, and I fail to see why libtool should interact with it. Using MacPorts gfortran rather than the one in /usr/bin is *not* the point, all I see is a fundamental failure to get a MacPorts port to play nice with the rest the OS
Change History (7)
comment:1 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | ryandesign@… added |
|---|---|
| Keywords: | libtool removed |
| Owner: | changed from macports-tickets@… to boeyms@… |
| Priority: | High → Normal |
comment:2 Changed 13 years ago by drkp (Dan Ports)
| Cc: | dports@… added |
|---|
In addition to being entirely unsupported, it seems particularly poor form for anything to install files into /usr/bin, since that directory ought to be reserved for Apple-installed files.
It would be useful to know where your gfortran came from, i.e. what package installed it. This has come up a few times before (#30018, #23684, #25417) but no one has had an answer to that!
comment:3 Changed 13 years ago by f.calboli@…
it comes from here:
http://r.research.att.com/ http://r.research.att.com/tools/
GNU Fortran 4.2.4 for Mac OS X 10.7 (Lion)
I would not know why other people have /usr/bin/gfortran, but I can tell you I put it there by choice!
comment:4 Changed 13 years ago by drkp (Dan Ports)
FWIW, I tried to reproduce this on Leopard and Snow Leopard (not having a spare Lion system to test with). libtool built fine even after installing the appropriate gfortran package, so it's apparently not as simple as just having that installed...
comment:5 Changed 12 years ago by boeyms@…
| Owner: | changed from boeyms@… to macports-tickets@… |
|---|
Reassigning to macports-tickets@… as I have relinquished ownership of this port.
comment:6 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | ryandesign@… removed |
|---|---|
| Owner: | changed from macports-tickets@… to ryandesign@… |
| Status: | new → assigned |
comment:7 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)
| Resolution: | → duplicate |
|---|---|
| Status: | assigned → closed |
Duplicate of #23684.
Replying to f.calboli@…:
Acceptable or not, it is a fact that third-party software installed in system locations (/, /usr/, /usr/local/) can and does interfere with MacPorts software. That is a general MacPorts issue that we do not know how to solve. Suggestions welcome.
Specifically for libtool, if we can figure out how to make libtool not care about /usr/bin/gfortran we should do that, but that will not change the fact that having gfortran there could cause problems for other ports too.