0.5.1 (and 0.4.0) fails configure
On OS X 10.7, configure fails wit this error. liblangtag-0.3 worked on the same machine.
checking for the suffix of module shared libraries... libtool: unknown option character `-' in: --config
Usage: libtool -static [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-sacLT]
Usage: libtool -dynamic [-] file [...] [-filelist listfile[,dirname]] [-arch_only arch] [-o output] [-install_name name] [-compatibility_version #] [-current_version #] [-seg1addr 0x#] [-segs_read_only_addr 0x#] [-segs_read_write_addr 0x#] [-seg_addr_table <filename>] [-seg_addr_table_filename <file_system_path>] [-all_load] [-noall_load]
.
configure: error: Unable to determine shared libreary suffix from libtool
Comments (6)
-
repo owner -
reporter I have libtool-2.4.2 installed. However, I found out the source of my problem. libtool-2.4.2 is installed as glibtool, whereas 'libtool' (which configure ends up using) is Apple's /usr/bin/libtool, which behaves differently. If I patch configure to use glibtool where it is checking for the suffix to add to shared modules, then liblangtag fully builds and passes tests. Thanks for suggesting where to look.
One question: I'm building liblangtag to package it for Fink (an OS X package manager). I was distributing the installed files into separate packages following Debian's lead, but I can't find what package they put liblangtag-ext-ldml-u.so and liblangtag-ext-ldml-t.so into. Do they belong alongside the main library? Or are they separate runtime elements that should be on their own? Or perhaps some other arrangement? Thanks for your help.
-
repo owner Those modules provides a optional handler for RFC6067, BCP 47 Extension U and RFC6497, BCP 47 Extension T. since there are no extra dependencies for modules, you just have an option to make them external libraries or built-ins so far. if you don't see them, that would means your library contains those extensions.
Hope that helps.
-
reporter Thanks for the explanation. This issue can probably be closed since the bug is not really in liblangtag. At worst, maybe it should check that 'libtool' is GNU libtool, but that might be too much work for very little gain.
-
repo owner Sure. I'm not sure if there are any generic way to detect it though. anyway, I'll close this at this moment. thanks.
-
repo owner - changed status to invalid
- Log in to comment
What the version of libtool are installed on your machine? does re-libtoolize help?