Opened 15 years ago
Closed 14 years ago
#21789 closed enhancement (fixed)
py26-mapnik fails when boost is not installed with +python26 variant
| Reported by: | distributed@… | Owned by: | dbsgeo@… |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.8.1 |
| Keywords: | Cc: | ryandesign (Ryan Carsten Schmidt) | |
| Port: | py26-mapnik |
Description
When I tried to install py26-mapnik it failed, because it could not be linked against -lboost_python_mt, even though boost is a dependency and therefore already installed.
The solution was to build boost with +python26. IIRC it is impossible to specify variants in the depencencies. Would it be possible to solve this problem another way, like maybe warning the user to build boost with the appropriate +pythonxy variant if building of mapnik fails?
Change History (4)
comment:1 Changed 15 years ago by mf2k (Frank Schima)
| Owner: | changed from macports-tickets@… to dbsgeo@… |
|---|---|
| Priority: | Low → Normal |
comment:2 Changed 15 years ago by dbsgeo@…
comment:4 Changed 14 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | ryandesign@… added |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
| Summary: | Mapnik dependencies → py26-mapnik fails when boost is not installed with +python26 variant |
Note: See
TracTickets for help on using
tickets.
Yes, this is a known issue, and is due to the lacking support in macports for specifying variants.
Ideally the boost port would be broken out into one port per boost library, so that a port like 'py26-boost' or 'libboost-python' could be selected. This would also make it much easier to rollback and re-install when the chronic problem of #21444 occurs (without having to wait for the whole boost port to re-compile, just to try to properly link libboost_python).
As far as your idea of trying to warn the user that their py26-mapnik build will fail, that would definitely be a step forward but does not address the main issue.