Skip to content

Fix for Issue #43: checks for the existence of glibtool using hash rather than testing for ... #44

Merged
merged 1 commit into from Dec 1, 2012

2 participants

@mdavid
Cherokee Project member
mdavid commented Dec 1, 2012

...the hardcoded path /usr/bin/glibtool. This ensures that glibtool and glibtoolize that are not located in /usr/bin (e.g. /usr/local/bin) can be found as long as their root folder is contained in the $PATH environment variable.

Apple uses their own version of libtool which is located at /usr/bin/libtool. The Gnu version of libtool (which autogen.sh is configured to look for) uses the g prefix (i.e. glibtool,glibtoolize.) On systems that ship with the Gnu libtool version, testing for the existence of /usr/bin/glibtool will in most cases return true. However, on Mac OS X it returns false regardless of whether you have the Gnu version of libtool installed somewhere else on the system (e.g. /usr/local/bin/glibtool as would be the case if you compiled and installed from source directly or via brew or similar OS X package management tool.) Using the hash command to determine if the glibtool command exists in any location rather than testing for the hardcoded existence of /usr/bin/glibtool is therefore the better overall cross-platform solution.

@mdavid mdavid checks for the existence of glibtool using hash rather than testing f…
…or the hardcoded path /usr/bin/glibtool. This ensures that glibtool and glibtoolize that are not located in /usr/bin (e.g. /usr/local/bin) can be found as long as their root folder is contained in the $PATH environment variable.
7fa9e44
@skinkie skinkie merged commit e43de1b into master Dec 1, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.