How about we build an binary package for OSX? Another alternative is a Hombrew recipe.
Regards, Elias On 7 May 2014 19:22, "Juergen Sauermann" <juergen.sauerm...@t-online.de> wrote: > Hi Peter, > > when I first looked at internationalization my impression was that it > could be a good idea, > in particular for ⎕NLT. > > After that saw a number of problems with translation and locales, and I > was several times > close to removing it again (and I may actually do that at some point in > time). > > Currently only a few major error messages (SYNTAX ERROR, VALUE ERROR, etc) > can be > translated to German. More detailed information via )MORE and debug > messages are not > translated. So removing gettext() altogether would not harm too much. > > My proposal would therefore be ./configure --without-nls and maybe > mention that in your nice Macintosh manual. > > Best Regards, > Jürgen > > > On 05/05/2014 10:21 PM, Peter Teeson wrote: > > 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 < > juergen.sauerm...@t-online.de> 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 > > > > >
