Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#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


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

    if test -r "$with_mrsid/lib/libltiesdk.a" ; then # v8+ esdk contains dsdk
      MRSID_LIBS="-lltiesdk $MRSID_LIBS"
    elif test -r "$with_mrsid/lib/libltidsdk.a" \
           -o -L "$with_mrsid/lib/" ; then
      MRSID_LIBS="-lltidsdk $MRSID_LIBS"
      MRSID_LIBS="-lltidsdk $MRSID_LIBS"


    if test -L "$MRSID_LIDAR_BASE/lib/"; then
      MRSID_LIDAR_LIBS="-L$MRSID_LIDAR_BASE/lib -llti_lidar_dsdk"
      MRSID_LIDAR_LIBS="-L$MRSID_LIDAR_BASE/lib/Release -llti_lidar_dsdk"

Change History (6)

comment:1 by Even Rouault, 13 years ago

Cc: kirk added

comment:2 by kirk, 13 years ago

Owner: changed from warmerdam to kirk

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.

comment:3 by Even Rouault, 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 kirk, 13 years ago

Resolution: fixed
Status: newclosed

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:5 by kirk, 13 years ago

Oops that branch revision should have read r21532.

comment:6 by kyngchaos, 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.

Note: See TracTickets for help on using tickets.