And so we have incompatible binaries.
I now know that gettext and libintl was built then with
libstdc++.
Why? Because I again downloaded the source from GNU and
grepped for libstdc++ and found it.
Whereas grepping for libc++ was not found.
However here is the Xcode setting for CLANG_CXX_LIBRARY
= libc++
and this is what GNU APL was built with- i.e. Apple's
default.
The interesting question is what to do about it?
(1) Change Xcode setting and thus diverge from Apple
default?
(2) Build gettext with libc++ - but should that not come
from the maintainer?
(I certainly don't have enough deep understanding to
go fiddling with the gettext auto tools stuff)
(3) For GNU APL on Macintosh ./configure --without-nls
For now I shall follow (3) but in the future it might be
nice to allow NLS support.
Not totally confident that I have analyzed this
correctly. What do you think?
respect….
Peter
P.S. Now leaving this rabbit trail and going back to
nabla and Editor 1
=============== supporting evidence ============
Here are some more details FWIW
using previously installed get text (in March)
Using a fresh SVN co and then ./configure, the terminal
log showed the following
…
checking whether NLS is requested… yes
…
checking for GNU gettext in libintl...
yes <<<<=====
checking whether to use NLS… yes
<<<<=====
So problem because of incompatible binaries
(Back in March I didn't understand the problem and just
reconfigured --without-nls)
Now the fresh SVN co showed up the issue again and forced
me to try to understand it.
On OS X 10.9 I have never installed gettext and
libintl.
Following the same steps as above the terminal log shows
…
checking whether NLS is requested… yes
…
checking for GNU gettext in libintl...
no <<<<=====
checking whether to use NLS… no
<<<=======
…
So no problem because no NLS
Hi Peter,
looks like all linker messages point to libintl. We
are checking for the
presence of libintl_gettext in configure.ac and that
check seem to pass (your config.log tells more).
And then the linker (which is the compiler under a
different name) complains.
That suggests that the compiler used by ./configure
us different from the compiler used in make.
This can often be cured by eg.
CXX=mycompiler ./configure
see INSTALL for more details. An alternative could
be ./configure --without_readline or playing around
with
--with-libintl-prefix= if you have both library
variants installed.
/// Jürgen
On 05/03/2014 11:53 PM, Peter Teeson wrote:
Sigh…..
Tracking down something in nabla I decided to
start absolutely clean and did a new SVN checkout.
I did the usual ./configure followed by make
and got this:
…..
Undefined
symbols for architecture x86_64:
"_libintl_bindtextdomain", referenced from:
_main in apl-main.o
"_libintl_gettext", referenced from:
Command::process_line(UCS_string&) in
apl-Command.o
Command::cmd_CHECK(std::ostream&) in
apl-Command.o
Command::cmd_DROP(std::ostream&,
std::vector<UCS_string,
std::allocator<UCS_string> >
const&) in apl-Command.o
Command::cmd_HELP(std::ostream&) in
apl-Command.o
Command::cmd_HOST(std::ostream&,
UCS_string const&) in apl-Command.o
Command::cmd_IN(std::ostream&,
std::vector<UCS_string,
std::allocator<UCS_string> >&,
bool) in apl-Command.o
Command::cmd_LIB(std::ostream&,
UCS_string const&) in apl-Command.o
...
"_libintl_setlocale", referenced from:
Quad_NLT::Quad_NLT() in apl-SystemVariable.o
Quad_NLT::assign(Value_P, char const*) in
apl-SystemVariable.o
"_libintl_textdomain", referenced from:
_main in apl-main.o
ld:
symbol(s) not found for architecture x86_64
clang:
error: linker command failed with exit code 1
(use -v to see invocation)
The reason is this:
"There are two implementations of the standard
C++ library available on OS X: libstdc++ and
libc++.
They are not binary compatible.
On OS X 10.8 and earlier libstdc++ is chosen by
default, on OS X 10.9 libc++ is chosen by default.
To ensure compatibility add -stdlib=libstdc++ to
the linking command."
I happen to be on 10.8 Mountain Lion. I know
10.9 has been out 6 months and I have been
building on it as a test.
But there are still lots of people on 10.8.
Do you feel it's worthwhile to still support OS
X less than 10.9?
respect….
Peter