Hi Jürgen:
OK I spent some time digging around and maybe I understand a bit more.
Based on the details below it is my understanding that
•gettext was built using libstdc++
•but GNU APL was built using libc++
And so we have incompatible binaries.
On OS X 10.8 I had previously, installed gettext which includes libintl in
/usr/local/lib so I could test NLS
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
On 2014-05-04, at 7:13 AM, Juergen Sauermann <[email protected]>
wrote:
> 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
>>
>
