bug#22153: Make check fails

2015-12-17 Thread Ludovic Courtès
Dennis Mungai  skribis:

> A few days ago, I repeated the build under /tmp and all unit tests passed.
> Could've been related to the issue above.

Yes, probably.

> I'd have to repeat the guix build above in the same directory once I'm
> logged on to the HPC's node to get you the requested results.

Sure.

Thanks for your feedback!

Ludo’.





bug#22186: Use {C,CPLUS,OBJC}_INCLUDE_PATH instead of CPATH

2015-12-17 Thread Ludovic Courtès
Andy Wingo  skribis:

> So!  CPATH is like -I but C_INCLUDE_PATH et al are like -isystem.
> Here's the docs for -isystem ("Preprocessor Options"):
>
> '-isystem DIR'
>  Search DIR for header files, after all directories specified by
>  '-I' but before the standard system directories.  Mark it as a
>  system directory, so that it gets the same special treatment as is
>  applied to the standard system directories.  If DIR begins with
>  '=', then the '=' will be replaced by the sysroot prefix; see
>  '--sysroot' and '-isysroot'.
>
> What is a system directory?  Well, it's searched for after all -I
> includes, but also header files in it are marked as system headers.
> Many warnings are not issued for system headers; search the manual for
> the phrase "system headers".  For example:
>
> '-Wsystem-headers'
>  Issue warnings for code in system headers.  These are normally
>  unhelpful in finding bugs in your own code, therefore suppressed.
>  If you are responsible for the system library, you may want to see
>  them.
>
> So.  We should be using C_INCLUDE_PATH instead of CPATH, to mark system
> headers as system headers.  Except that C_INCLUDE_PATH only works for C,
> so we need to also set CPLUS_INCLUDE_PATH and OBJC_INCLUDE_PATH.  And
> that's the proposal of this bug :)

The intent of this “system header” classification, AIUI, is to not
bother users with issues in libc headers.

The problem is that if we use C_INCLUDE_PATH & co., every header in the
search path, not just libc’s, would now be considered a system header,
and thus exempt from warnings.  This would be undesirable.

Here’s an experiment:

--8<---cut here---start->8---
$ guix environment --ad-hoc gcc ld-wrapper glibc binutils --container
sh-4.3# gcc -Werror=type-limits -O2 -c sysp.c
In file included from sysp.c:1:0:
/gnu/store/n96gwg9fwmxmz1bhy219v3vvmsjsk7gz-glibc-2.22/include/wchar.h: In 
function 'wctob':
/gnu/store/n96gwg9fwmxmz1bhy219v3vvmsjsk7gz-glibc-2.22/include/wchar.h:397:47: 
error: comparison of unsigned expression >= 0 is always true 
[-Werror=type-limits]
 { return (__builtin_constant_p (__wc) && __wc >= L'\0' && __wc <= L'\x7f'
   ^
cc1: some warnings being treated as errors
sh-4.3# echo $CPATH
/gnu/store/lq595bjrgav37b05bmmafigwargasy8k-binutils-2.25.1/include:/gnu/store/n96gwg9fwmxmz1bhy219v3vvmsjsk7gz-glibc-2.22/include:/gnu/store/14xgip7wslikzqfkr67vln0kpcclwy37-linux-libre-headers-3.14.37/include:/gnu/store/0wq6hcbfjh5clyz6pjcqxjkl60rmijjf-gcc-5.2.0/include
sh-4.3# export 
CPATH=/gnu/store/lq595bjrgav37b05bmmafigwargasy8k-binutils-2.25.1/include:/gnu/store/14xgip7wslikzqfkr67vln0kpcclwy37-linux-libre-headers-3.14.37/include:/gnu/store/0wq6hcbfjh5clyz6pjcqxjkl60rmijjf-gcc-5.2.0/include
sh-4.3# gcc -Werror=type-limits -O2 -c sysp.c
--8<---cut here---end--->8---

Where sysp.c is:

--8<---cut here---start->8---
#include 

int foo () { return 42; }
--8<---cut here---end--->8---

Compare with this:

--8<---cut here---start->8---
$ guix environment --ad-hoc gcc ld-wrapper -e '(@@ (gnu packages commencement) 
glibc-final)' binutils --container
sh-4.3# gcc -Werror=type-limits -O2 -c sysp.c
sh-4.3# echo $CPATH
/gnu/store/lq595bjrgav37b05bmmafigwargasy8k-binutils-2.25.1/include:/gnu/store/qv7bk62c22ms9i11dhfl71hnivyc82k2-glibc-2.22/include:/gnu/store/lyn2331ilik14yy2jqhndshvxmv9r6w5-linux-libre-headers-3.14.37/include:/gnu/store/0wq6hcbfjh5clyz6pjcqxjkl60rmijjf-gcc-5.2.0/include
--8<---cut here---end--->8---

The lesson here is that, if the libc headers that are in CPATH come from
the libc that GCC was built against, then they do not lose their
system-headerness.


Now, when using ‘gcc-toolchain’, CPATH contains an entry that is a
*symlink* to libc.  So from the point of view of libcpp, these are not
system headers.  Thus:

--8<---cut here---start->8---
$ guix environment --ad-hoc gcc-toolchain --container
sh-4.3# gcc -Werror=type-limits -O2 -c sysp.c
In file included from sysp.c:1:0:
/gnu/store/q7k2dc3ylpjnjlhb59f01bxxab8fjxr6-gcc-toolchain-5.2.0/include/wchar.h:
 In function 'wctob':
/gnu/store/q7k2dc3ylpjnjlhb59f01bxxab8fjxr6-gcc-toolchain-5.2.0/include/wchar.h:397:47:
 error: comparison of unsigned expression >= 0 is always true 
[-Werror=type-limits]
 { return (__builtin_constant_p (__wc) && __wc >= L'\0' && __wc <= L'\x7f'
   ^
cc1: some warnings being treated as errors
sh-4.3# echo $CPATH
/gnu/store/q7k2dc3ylpjnjlhb59f01bxxab8fjxr6-gcc-toolchain-5.2.0/include
--8<---cut here---end--->8---

This particular problem with gcc-toolchain in ‘guix environment’ is
solved by this patch:

bug#22196: Ansible, python executable on remote host

2015-12-17 Thread Al McElrath

Hi,

I had some trouble with ansible that I'd like to share. I believe it
tries to use the same path to the python executable on the remote host
as exists locally, which is problematic for guix:

'/bin/sh: 1: 
/gnu/store/5isi4xqg1jr5rqbr6pfap28fw5116dnr-python-2.7.10/bin/python: not found'

I imagine this can be a problem for non-guix users too, and there's a
workaround in the form of a setting to specify the remote python path,
"ansible_python_interpreter":

http://docs.ansible.com/ansible/intro_inventory.html#list-of-behavioral-inventory-parameters

Not quite a bug, but maybe this will help someone else.





bug#22153: Make check fails

2015-12-17 Thread Dennis Mungai
Hello,

And sorry for replying so late.

A few days ago, I repeated the build under /tmp and all unit tests passed.
Could've been related to the issue above.
I'd have to repeat the guix build above in the same directory once I'm
logged on to the HPC's node to get you the requested results.

Regards,

Dennis.

On 13 December 2015 at 14:09, Ludovic Courtès  wrote:

> Hi,
>
> Dennis Mungai  skribis:
>
> > +
> GUIX_DAEMON_SOCKET=/home/administrator/source.build/GCC.buildenv/guix-0.9.0/t-register-39139/var/guix/guix/daemon-socket/socket
> > + export NIX_IGNORE_SYMLINK_STORE NIX_STORE_DIR NIX_STATE_DIR
> NIX_LOG_DIR NIX_DB_DIR GUIX_DAEMON_SOCKET
> > ++ echo
> /home/administrator/source.build/GCC.buildenv/guix-0.9.0/t-register-39139/var/guix/guix/daemon-socket/socket
> > ++ wc -c
> > + '[' 109 -ge 108 ']'
> > + exit 77
>
> The build directory name is very long, which means that we are a likely
> to hit the kernel’s limitation on the length of socket file names, as in
> the snippet above.
>
> What does this command:
>
>   grep ac_cv_guix_test_socket_file_name_length config.log
>
> return?
>
> At configure time, one normally gets a warning:
>
>   socket file name limit may be exceeded when running tests
>
> (This is not an error because there’s no problem if you don’t run ‘make
> check’.)
>
> In your case I think you would have to build from a shorter directory.
>
> HTH,
> Ludo’.
>


bug#22186: Use {C,CPLUS,OBJC}_INCLUDE_PATH instead of CPATH

2015-12-17 Thread Ludovic Courtès
Efraim Flashner  skribis:

> Are there other ones that could be set? Every time I compile it I see options
> for java and go.

GCJ honors ‘CLASSPATH’ (see gcc/java/jcf-path.c in the GCC tree), but
the Go front-end doesn’t seem to have anything similar.

Ludo’.





bug#22186: Use {C,CPLUS,OBJC}_INCLUDE_PATH instead of CPATH

2015-12-17 Thread Andy Wingo
On Wed 16 Dec 2015 20:18, Efraim Flashner  writes:

>> We should be using C_INCLUDE_PATH instead of CPATH, to mark system
>> headers as system headers.  Except that C_INCLUDE_PATH only works for
>> C, so we need to also set CPLUS_INCLUDE_PATH and OBJC_INCLUDE_PATH.
>> And that's the proposal of this bug :)
>
> Are there other ones that could be set? Every time I compile it I see options
> for java and go.

No, the only ones mentioned in the manual are the ones I mention above.
To me this makes sense, as ObjC and C++ can include C, but that is not
the case for Java and Go.

Andy