Opened 10 years ago
Closed 10 years ago
#51618 closed defect (fixed)
glfw @3.2: install_name is not set properly
| Reported by: | inDigiNeous (Sakari Lehtonen) | Owned by: | michaelld (Michael Dickens) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.3.4 |
| Keywords: | Cc: | ||
| Port: | glfw |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
I just updated to GLFW 3.2 release from the previous one. Now when building my project, even when using pkg-config to get the correct library directories, the resulting binary points to
lib/libglfw.3.dylib (compatibility version 3.0.0, current version 3.2.0)
When obviously, it should point to
'/opt/local/lib'
pkg-config gives the correct info:
pkg-config --libs glfw3 -L/opt/local/lib -lglfw
And linkin works, but when I try to run my resulting binary,
dyld: Library not loaded: lib/libglfw.3.dylib Referenced from: /Users/sakari/dvl/geometrify/geometrify/src/build/geometrify Reason: image not found fish: “build/geometrify -s scripts/t...” terminated by signal SIGTRAP (Trace or breakpoint trap)
I can fix this temporarily easily of course, but I have no idea why this happens, maybe the path is wrong in the build process ?
Change History (3)
comment:1 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
| Description: | modified (diff) |
|---|---|
| Keywords: | library build linking removed |
| Owner: | changed from macports-tickets@… to michaelld@… |
| Priority: | High → Normal |
| Summary: | GLFW3.2 has wrong lib dir when building with → glfw @3.2: install_name is not set properly |
comment:2 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)
I notice that the glfw port is overwriting configure.args. Normally ports using the cmake portgroup should append to, not overwrite, configure.args. The cmake portgroup sets arguments in configure.args that should cause the correct install_name to be used.
comment:3 Changed 10 years ago by michaelld (Michael Dickens)
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Should be fixed in r149391. I also tweaked the configure.args to append; good catch!

Sounds like the
install_nameis not being set correctly.