Ticket #34901 (closed defect: fixed)
cctools fails to build when prefix is /usr/local
| Reported by: | macports@… | Owned by: | macports-tickets@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.1.1 |
| Keywords: | Cc: | mfeiri@…, jeremyhu@…, ryandesign@… | |
| Port: | cctools |
Description
during build of cctools, an attempt is made to strip a library that was not built the build fails to complete, preventing upgrade/installation of other dependent ports
Attachments
Change History
comment:1 Changed 11 months ago by ryandesign@…
- Status changed from new to closed
- Cc mfeiri@…, jeremyhu@… added
- Resolution set to invalid
- Port set to cctools
The log says:
:info:build i686-apple-darwin10-llvm-g++-4.2: /usr/local/local/lib/libprunetrie.a: No such file or directory
This should not happen unless you have things in /usr/local. Because of this type of interference, we don't support the use of MacPorts when you have things installed in /usr/local. Please move or remove /usr/local, clean cctools, and try again.
comment:2 Changed 11 months ago by macports@…
- Status changed from closed to reopened
- Resolution invalid deleted
Moving the entire ports tree for one error in a port is unsupported. Perhaps that would be practical if if not for the fact that moving the ports tree with a restart from scratch, rebuilding everything, is unsupported.
Please come up with a real solution for the error. I don't give a flying fuck what path it's looking in, that file doesn't exist anywhere and won't in the current state of the port. The path should not matter so long as the environment is setup, which it is. I should be able to install to any path I want, be it /usr/local or /you/mother/was/a/hamster/and/your/father/smelt/of/elderberries! Any piece of software than fails when simply installed to non-default location is defective. That's simply a fact. Suck it up and fix your bug.
comment:3 Changed 11 months ago by jeremyhu@…
- Status changed from reopened to closed
- Resolution set to wontfix
Yes, you can install to any path you want, but /usr/... is specifically not supported. /usr is owned by the system. You're free to choose /you/mother/was/a/hamster/and/your/father/smelt/of/elderberries as your MacPorts prefix if that is what you desire.
You are being hostile and not actually providing any useful information.
comment:4 Changed 11 months ago by macports@…
- Status changed from closed to reopened
- Resolution wontfix deleted
I provided a complete log. Is that not useful information? I'm sorry, but I'm afraid it is. Too bad if you don't like what it says.
Perhaps /usr is owned by the system, but /usr/local is not. Its up for grabs and nothing else seems to have a problem living there. Once upon a time, that might have been the default for MacPorts or one of the predecessors. Installing ports to /usr/local is a well accepted standard across multiple platforms. The choice to make it unsupported is probably the worst choice ever made by this project.
Perhaps I start getting hostile because EVERY time I report a bug the immediate reaction is dismissive and/or 'you fault'. Well, it is not my fault the fucking directory changed to be more-Linux like by default, nor is it my fault that your shit-pile is so fucking fragile. It makes you people look like some real class A geniuses. Maybe I'm pissed because not only is Apple flushing Mac OS down the toilet, but MacPorts is trying to screw itself too making it that much more difficult to run one of the earlier working OS X releases with modern software.
If you actually took the time to look into this you might see the solution is not that bad. Look at misc/Makefile, notice this little gem LIB_PRUNETRIE = /usr/local/local/lib/libprunetrie.a Make that path sane and guess what happens, ah yes, suddenly the build can complete and on to the next. Maybe instead of blaming my path, figure out why it's got the wrong path in that file.
comment:5 Changed 11 months ago by ryandesign@…
- Status changed from reopened to closed
- Cc ryandesign@… added
- Resolution set to fixed
- Summary changed from cctools fails to build to cctools fails to build when prefix is /usr/local
I did not realize on my first reading of your log file that you had set your MacPorts prefix to /usr/local. Now that I understand the problem and see what's causing it, I believe I have fixed it in r94471.
Please remember that having your MacPorts prefix set to /usr/local is unsupported. I apologize about this, but we do not have the resources to support every possible user configuration, and specifically setting prefix to /usr/local is known to cause other problems, so we have decided to focus our limited support resources on other areas. When you configured MacPorts with prefix /usr/local, it printed this message:
configure: error: Installing MacPorts into /usr/local is not supported. If you understand this and wish to do so anyway, pass --with-unsupported-prefix to configure.
By proceeding past this message and supplying the --with-unsupported-prefix option, you understood that you were running an unsupported configuration. That means it may work for you, but if it does not, we do not provide support for it. If you encounter another problem, and can work out why it is occurring, and how to fix it, and can supply patch to do so, then we would likely be willing to consider incorporating that patch.
builid log