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

Fails to build with icu v76.1 #26

Open
merkys opened this issue Jan 7, 2025 · 3 comments
Open

Fails to build with icu v76.1 #26

merkys opened this issue Jan 7, 2025 · 3 comments
Assignees

Comments

@merkys
Copy link
Contributor

merkys commented Jan 7, 2025

Debian will migrate to icu v76.1 soon. It has been reported that cif_api v0.4.2 fails to build with icu v76.1 with the following output:

gcc -DHAVE_CONFIG_H -I. -I..  -std=c89 -pedantic   -I ../uthash -Wall 
-Wextra -Wformat=2 -Winit-self -Wno-switch -Wno-switch-default 
-Wstrict-aliasing=2 -Wshadow -Wpointer-arith -Wc++-compat -Wcast-align 
-Wwrite-strings -Waggregate-return -Wstrict-prototypes 
-Wmissing-prototypes -Wredundant-decls -Wnested-externs 
-Wno-missing-field-initializers  -Wdate-time -D_FORTIFY_SOURCE=3  -g -O3 
-Werror=implicit-function-declaration -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -ffile-prefix-map=/<<PKGBUILDDIR>>=. 
-flto=auto -ffat-lto-objects -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-fcf-protection 
-fdebug-prefix-map=/<<PKGBUILDDIR>>=/usr/src/cif-api-0.4.2-5build2 -c -o 
test_create_block1.o `test -f 'tests/test_create_block1.c' || echo 
'./'`tests/test_create_block1.c
gcc -DHAVE_CONFIG_H -I. -I..  -std=c89 -pedantic   -I ../uthash -Wall 
-Wextra -Wformat=2 -Winit-self -Wno-switch -Wno-switch-default 
-Wstrict-aliasing=2 -Wshadow -Wpointer-arith -Wc++-compat -Wcast-align 
-Wwrite-strings -Waggregate-return -Wstrict-prototypes 
-Wmissing-prototypes -Wredundant-decls -Wnested-externs 
-Wno-missing-field-initializers  -Wdate-time -D_FORTIFY_SOURCE=3  -g -O3 
-Werror=implicit-function-declaration -fno-omit-frame-pointer 
-mno-omit-leaf-frame-pointer -ffile-prefix-map=/<<PKGBUILDDIR>>=. 
-flto=auto -ffat-lto-objects -fstack-protector-strong 
-fstack-clash-protection -Wformat -Werror=format-security 
-fcf-protection 
-fdebug-prefix-map=/<<PKGBUILDDIR>>=/usr/src/cif-api-0.4.2-5build2 -c -o 
test_create_block2.o `test -f 'tests/test_create_block2.c' || echo 
'./'`tests/test_create_block2.c
In file included from /usr/include/unicode/ptypes.h:46,
                 from /usr/include/unicode/umachine.h:46,
                 from /usr/include/unicode/utypes.h:38,
                 from /usr/include/unicode/ustring.h:21,
                 from tests/test_create_block1.c:27:
tests/test_create_block1.c: In function ‘main’:
tests/test_create_block1.c:35:5: error: pasting "u" and ""block"" does 
not give a valid preprocessing token
   35 |     U_STRING_DECL(block_code, "block", 6);
      |     ^~~~~~~~~~~~~
tests/test_create_block1.c:35:5: error: ‘u’ undeclared (first use in 
this function)
tests/test_create_block1.c:35:5: note: each undeclared identifier is 
reported only once for each function it appears in
tests/test_create_block1.c:35:31: error: expected ‘,’ or ‘;’ before 
string constant
   35 |     U_STRING_DECL(block_code, "block", 6);
      |                               ^~~~~~~
@jcbollinger jcbollinger self-assigned this Jan 8, 2025
@jcbollinger
Copy link
Contributor

From the diagnostics, ICU 76.1 has started producing UTF-16 string literals in some of their public macros. This is a feature introduced into C at C11, whereas CIF API 0.4.2 compiles in C89 mode, largely so as to help (me) maintain source compatibility with that version. One cannot fault ICU for using C language features that have been around for more than a decade, even if the change to doing so produces issues such as this one.

Probably this can be fixed by changing the compiler flags for GCC to omit -std=c89.

@jcbollinger
Copy link
Contributor

jcbollinger commented Jan 8, 2025

Interesting. I couldn't even get a successful configure run against ICU 76.1. It's definitely an issue of specifying the language standard as c89. If one somehow did get successful configuration, then they could probably work around the compilation issue by overriding the language standard via the make command line, maybe:

make CFLAGS="-std=c11"

That would be necessary for make check, too. It shouldn't be necessary for make install, but it won't hurt in that case.

@merkys
Copy link
Contributor Author

merkys commented Jan 9, 2025

Thanks for a detailed analysis of the issue. Indeed, dropping -std=c89 solves the issue for me.

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

No branches or pull requests

2 participants