Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

FreeBSD: 0.8.0 fails to build (autoreconf) #59

Open
nunotexbsd opened this issue Mar 29, 2023 · 6 comments · May be fixed by #61
Open

FreeBSD: 0.8.0 fails to build (autoreconf) #59

nunotexbsd opened this issue Mar 29, 2023 · 6 comments · May be fixed by #61

Comments

@nunotexbsd
Copy link

Hello,

Trying to update FreeBSD paps port but getting error:

In file included from format_from_dict.cc:23:
./format_from_dict.h:30:23: error: no template named 'variant' in namespace 'std'
using scalar_t = std::variant<int, std::string, double, std::time_t>;
                 ~~~~~^
./format_from_dict.h:31:38: error: use of undeclared identifier 'scalar_t'
using dict_t = std::map<std::string, scalar_t>;
                                     ^
./format_from_dict.h:36:30: error: unknown type name 'dict_t'
                             dict_t dict);
                             ^
format_from_dict.cc:28:32: error: unknown type name 'scalar_t'
static string scalar_to_string(scalar_t scalar,
                               ^
format_from_dict.cc:65:25: error: unknown type name 'dict_t'
                        dict_t dict)
                        ^
--- paps-paps.o ---
In file included from paps.cc:42:
./format_from_dict.h:30:23: error: no template named 'variant' in namespace 'std'
using scalar_t = std::variant<int, std::string, double, std::time_t>;
                 ~~~~~^
./format_from_dict.h:31:38: error: use of undeclared identifier 'scalar_t'
using dict_t = std::map<std::string, scalar_t>;
                                     ^
./format_from_dict.h:36:30: error: unknown type name 'dict_t'
                             dict_t dict);
                             ^
--- paps-format_from_dict.o ---

Any hints on why this build error happens?

Thanks,

Full log: https://people.freebsd.org/~eduardo/logs/paps/paps-0.8.0.log
PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270515

@nunotexbsd
Copy link
Author

After adding:
USES+= compiler:c++17-lang
USE_CXXSTD= c++17

===>  Building for paps-0.8.0
/usr/bin/make  all-recursive
Making all in src
c++ -DHAVE_CONFIG_H -I. -I..  -DGETTEXT_PACKAGE='"paps"' -DDATADIR='"/usr/local/"'   -I/usr/local/include/pango-1.0 -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/harfbuzz -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -I/usr/local/include/fribidi -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -D_THREAD_SAFE -D_THREAD_SAFE -D_THREAD_SAFE -D_THREAD_SAFE -pthread -D_THREAD_SAFE -D_THREAD_SAFE -I/usr/local/include -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing   -std=c++17 -MT paps-paps.o -MD -MP -MF .deps/paps-paps.Tpo -c -o paps-paps.o `test -f 'paps.cc' || echo './'`paps.cc
paps.cc:703:3: error: use of undeclared identifier 'textdomain'
  textdomain(GETTEXT_PACKAGE);
  ^
paps.cc:704:3: error: use of undeclared identifier 'bindtextdomain'
  bindtextdomain(GETTEXT_PACKAGE, DATADIR "/locale");
  ^
paps.cc:705:3: error: use of undeclared identifier 'bind_textdomain_codeset'
  bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8");
  ^
3 errors generated.
*** Error code 1

@dov
Copy link
Owner

dov commented Mar 29, 2023

Thanks. I'll add the two flags to the default compilation. Regarding gettext I don't have much experience with it. @tagoh can you help? Did you try compiling with meson?

@nunotexbsd nunotexbsd changed the title FreeBSD: 0.8.0 fails to build FreeBSD: 0.8.0 fails to build (autoreconf) Mar 29, 2023
@nunotexbsd
Copy link
Author

@dov

Builds fine with meson!
Also it adds c++17 to build by default.

Since meson is a newer build system than autoreconf (https://docs.freebsd.org/en/books/porters-handbook/book/#uses-autoreconf), port should use meson. Same for cmake when applicable.

I've updated port for meson use and I'm waiting on #60 because of 32bit support.

Is it good idea to leave this pr open so a solution could be found for autoreconf build?

Thanks

@tagoh
Copy link
Contributor

tagoh commented Mar 29, 2023

@dov I didn't but I just tried to switch the build system to meson and that works for me.
For gettext errors, those symbols are basically available on glibc on Linux though, BSD libc may not have. You need to make those lines conditional with ENABLE_NLS.
Aside from that, AM_GLIB_GNU_GETTEXT m4 macro is deprecated. You may want to replace it with AM_GNU_GETTEXT_VERSION and AM_GNU_GETTEXT. See https://www.gnu.org/software/gettext/manual/html_node/AM_005fGNU_005fGETTEXT.html

@eli-schwartz
Copy link

This is version-guarded.

paps/src/paps.cc

Lines 54 to 67 in 92cadd6

#if ENABLE_NLS
#include <libintl.h>
#define _(str) gettext(str)
#ifdef gettext_noop
#define N_(str) gettext_noop(str)
#else
#define N_(str) (str)
#endif
#else /* NLS is disabled */
#define _(str) (str)
#define N_(str) (str)
#endif

This isn't?

paps/src/paps.cc

Lines 702 to 705 in 92cadd6

/* Setup i18n */
textdomain(GETTEXT_PACKAGE);
bindtextdomain(GETTEXT_PACKAGE, DATADIR "/locale");
bind_textdomain_codeset (GETTEXT_PACKAGE, "UTF-8");

On the other hand, what's this?

paps/meson.build

Lines 44 to 45 in 92cadd6

# Assume we have nls, since paps doesn't compile without it
cdata.set('ENABLE_NLS',1)

@tagoh
Copy link
Contributor

tagoh commented Mar 30, 2023

Yes, 2nd quote is what compiler claimed as errors. These lines is required to make paps localized. I'm wondering if this localization support really prevents to build. it can be still optional.
For 3rd quote (and localization support in meson build in general), we need to add something like https://mesonbuild.com/Localisation.html#mesonbuild

Apparently current meson.build doesn't have.

tagoh added a commit to tagoh/paps that referenced this issue Mar 30, 2023
This contains a fix of the build fail with enabling
NLS support on BSD-based system.

Fixes dov#59
@tagoh tagoh linked a pull request Mar 30, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants