[sword-devel] Mac linking bug? Autotools bug?

[Greg Hellings]

Replying to myself...

On Wed, Nov 26, 2008 at 12:59 AM, Greg Hellings <greg.hellings at gmail.com> wrote:
> I'm building the current SVN on my Mac and have the following issue -
> autogen.sh does not find libtoolize, but the autogen.sh script
> continues anyway, generating a configure script, but no Makefile.in
> because of missing ltmain.sh.  Now, with Macports intsalled, I have
> glibtoolize in my path, which I just linked to libtoolize, and
> everything seems to be churning along just fine.  Perhaps, though,
> autogen.sh should error out as soon as it fails to find libtoolize.
> Also, since many systems which have built-in BSD tools and also the
> possibility of added GNU tools of the same name (Mac OS X and Solaris
> come to mind first) will use the convention of prepending the letter
> 'g' to the GNU version of the tools, perhaps the autogen.sh should
> look for both libtoolize and glibtoolize?
>
> Also, after building the library, I get the following lovely message:
> sword-svn-build hellings1$ utilities/diatheke/diatheke
> dyld: Symbol not found:
> __ZN5sword10InstallMgr32refreshRemoteSourceConfigurationEv
>  Referenced from:
> /Users/hellings1/Documents/build/sword-svn-build/lib/.libs/libsword-1.5.11.dylib
>  Expected in: flat namespace
>
> Trace/BPT trap
>
> Am I the only one, and does this seem relegated to OS X?
>
> --Greg
>

The problem exists also in Linux, where I got an error at linking time
as I usually expect.
sword::InstallMgr::refreshRemoteSourceConfiguration() is declared as
virtual in the header, but absolutely no instantiation of the method
is ever given (aren't they usually set as = 0; in the header if there
truly is no default implementation?).  For now I just set
InstallMgr::refreshRemoteSourceConfiguration() { return -1; } in
installmgr.cpp since I couldn't find the method referenced from any
other files with a grep and moved on, since I'm actually interested in
the issue with the filters.

--Greg