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

get_linux_libc_include_path is sensitive to locale #1165

Closed
avsej opened this Issue Jun 28, 2018 · 1 comment

Comments

Projects
None yet
2 participants
@avsej

avsej commented Jun 28, 2018

The code, which is parsing output of cc, should expect that compiler might emit localized messages. For example, on my system:

$ cc -E -Wp,-v -xc /dev/null
se descarta el directorio inexistente "/usr/lib/gcc/x86_64-redhat-linux/8/include-fixed"
se descarta el directorio inexistente "/usr/lib/gcc/x86_64-redhat-linux/8/../../../../x86_64-redhat-linux/include"
la búsqueda de #include "..." inicia aquí:
la búsqueda de #include <...> inicia aquí:
 /usr/lib/gcc/x86_64-redhat-linux/8/include
 /usr/local/include
 /usr/include
Fin de la lista de búsqueda.
# 1 "/dev/null"
# 1 "<interno>"
# 1 "<línea-de-órdenes>"
# 31 "<línea-de-órdenes>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<línea-de-órdenes>" 2
# 1 "/dev/null"

While this code clearly expects english locale:

zig/src/analyze.cpp

Lines 4427 to 4436 in 2fa588e

if (found_search_paths) {
if (strcmp(prev_newline, "End of search list.") == 0) {
break;
}
search_paths.append(prev_newline);
} else {
if (strcmp(prev_newline, "#include <...> search starts here:") == 0) {
found_search_paths = true;
}
}
and output like this:

$ LANG=C cc -E -Wp,-v -xc /dev/null
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/8/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/x86_64-redhat-linux/8/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-redhat-linux/8/include
 /usr/local/include
 /usr/include
End of search list.
# 1 "/dev/null"
# 1 "<built-in>"
# 1 "<command-line>"
# 31 "<command-line>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "<command-line>" 2
# 1 "/dev/null"

Patch like this fixes the issue:

diff --git i/src/analyze.cpp w/src/analyze.cpp
index 3c81d9ff..d18ca4b2 100644
--- i/src/analyze.cpp
+++ w/src/analyze.cpp
@@ -4409,6 +4409,7 @@ Buf *get_linux_libc_include_path(void) {
     Buf *out_stderr = buf_alloc();
     Buf *out_stdout = buf_alloc();
     int err;
+    setenv("LANG", "C", 1);
     if ((err = os_exec_process(cc_exe, args, &term, out_stderr, out_stdout))) {
         zig_panic("unable to determine libc include path: executing C compiler: %s", err_str(err));
     }

But I imagine that would be great if os_exec_process accept pointer to environment like execle.

@andrewrk andrewrk added this to the 0.3.0 milestone Jun 28, 2018

@andrewrk andrewrk added the bug label Jun 28, 2018

@andrewrk andrewrk closed this in 291afcf Jul 3, 2018

@andrewrk

This comment has been minimized.

Member

andrewrk commented Jul 3, 2018

Thanks for the report. Instead of setting an environment variable, I modified the code to look for lines that start with a space.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment