Re: [Bug-apl] Linker error libstdc++ vs Libc++

[Peter Teeson]

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 <address@hidden> 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