#3910 closed defect (fixed)
configure checks for platform-specific *.so for mrsid/lidar
Reported by: | kyngchaos | Owned by: | kirk |
---|---|---|---|
Priority: | normal | Milestone: | 1.8.0 |
Component: | ConfigBuild | Version: | svn-trunk |
Severity: | normal | Keywords: | |
Cc: | kirk |
Description
To decide whether to add "Release/" to the base path for linking MrSID and Lidar DSDKs, configure checks for the existence of a .so shared library. This only works on linux, and on OS X it will always fall thru to using "Release/", with the ver 8 DSDK which includes shared libraries. (the v7 DSDK has a .a static library, so the mrsid test works there.)
It needs to also test for *.dylib.
The relevant blocks in configure.in:
if test -r "$with_mrsid/lib/libltiesdk.a" ; then # v8+ esdk contains dsdk _LIBPART=lib MRSID_LIBS="-lltiesdk $MRSID_LIBS" elif test -r "$with_mrsid/lib/libltidsdk.a" \ -o -L "$with_mrsid/lib/libltidsdk.so" ; then _LIBPART=lib MRSID_LIBS="-lltidsdk $MRSID_LIBS" else _LIBPART=lib/Release MRSID_LIBS="-lltidsdk $MRSID_LIBS" fi
and
if test -L "$MRSID_LIDAR_BASE/lib/liblti_lidar_dsdk.so"; then MRSID_LIDAR_LIBS="-L$MRSID_LIDAR_BASE/lib -llti_lidar_dsdk" MRSID_LIDAR_INCLUDE="-I$MRSID_LIDAR_BASE/include" else MRSID_LIDAR_LIBS="-L$MRSID_LIDAR_BASE/lib/Release -llti_lidar_dsdk" MRSID_LIDAR_INCLUDE="-I$MRSID_LIDAR_BASE/include" fi
Change History (6)
comment:1 by , 13 years ago
Cc: | added |
---|
comment:2 by , 13 years ago
Owner: | changed from | to
---|
comment:3 by , 13 years ago
It looks safe to port to 1.8 branch. You can do it now as the tag for 1.8.0 as already been created. Once this is done, we just need the milestone 1.8.1 to be created to mark the ticket as being resolved for that milestone
comment:4 by , 13 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I've discovered that the MrSID SDK version 8.0.0 has a packaging problem. It should have softlinks for the .dylib but it has a duplicate of the library instead. As a workaround, I've relaxed the file test in configure so it is not insisting on a softlink. This change has been committed to the trunk (r21531) and is now ported to the 1.8 branch as well (r215321), for release in 1.8.1.
comment:6 by , 13 years ago
good catch. I hadn't had a chance to try the fix before r21531, but I did notice the duplication and had made my own symlink, so I probably wouldn't have had a problem. Kind of annoying when developers package software and symlinks get expanded to a full clone, especially with large file sizes.
I have committed a fix for this on the trunk (r21529). I believe it is too late to get it in 1.8.0. Awaiting word from Frank before marking this as resolved and possibly porting the fix to the 1.8 branch for a subsequent release.