verbose build for ati

[ZeroChaos-]

While ati is building it looks like this:
building for ATI RV730
building for Loveland
building for Cypress
building for Cayman
building for Juniper

While nvidia looks like this:
x86_64-pc-linux-gnu-gcc -DPACKAGE_NAME="hashkill" -DPACKAGE_TARNAME="hashkill" -DPACKAGE_VERSION="0.3.1" -DPACKAGE_STRING="hashkill\ 0.3.1" -DPACKAGE_BUGREPORT="[email protected]" -DPACKAGE_URL="" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" -DPACKAGE="hashkill" -DVERSION="0.3.1" -DHAVE_TERMIOS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_FCNTL_H=1 -DHAVE_STDLIB_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_STRING_H=1 -DHAVE_UNISTD_H=1 -DHAVE_OPENSSL_MD5_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_ZLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDDEF_H=1 -DHAVE_PTRDIFF_T=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DHAVE_BZERO=1 -DHAVE_STRSTR=1 -DHAVE_SYSINFO=1 -DHAVE_STRERROR=1 -DHAVE_ENDPWENT=1 -DHAVE_GETCWD=1 -DHAVE_STRCHR=1 -DHAVE_STRCSPN=1 -DHAVE_STRTOUL=1 -DHAVE_MEMSET=1 -DHAVE_STRTOL=1 -DHAVE_ATEXIT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MUNMAP=1 -DHAVE_SETENV=1 -DHAVE_MEMCHR=1 -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DLSTAT_FOLLOWS_SLASHED_SYMLINK=1 -DHAVE_SSE2=/**/ -I. -msse2 -DHAVE_JSON_JSON_H -fPIC -O3 -fomit-frame-pointer -momit-leaf-frame-pointer -Wall -Wno-format -ftree-vectorize -DBINDIR="/usr/bin" -DDATADIR="/usr/share" -pthread -Wno-unused-value -Wno-unused-result -Wno-switch -D_7ZIP_ST -flto -fwhole-program -Wno-psabi -Os -march=native -pipe -c -o hashkill-sha1_sse2.o test -f 'sha1_sse2.c' || echo './'sha1_sse2.c

When ati-compiler crashes, there is essentially no useful information about what is going on (as there already is with nvidia). Please verbosify the ati output. At your discretion, I'm fine with verbose being an option for the build instead of default..

[gat3way]

Should be better now with the latest commit. Also increased nvidia compiler's verbosity.

[ZeroChaos-]

amd verbosity is certainly better now:

Building amd_vbulletin for ATI RV730
Building amd_mysql5 for ATI RV730
Building amd_sha1 for Cypress
Building amd_vbulletin_long for ATI RV710
Building amd_mysql5_long for ATI RV710
Building amd_md4 for ATI RV730
Building amd_md5_passsalt for Cypress
Building amd_ipb2 for ATI RV730
Building amd_sha1_passsaltu_long for ATI RV730
Building amd_sha1_passsalt_long for ATI RV730
Building amd_pixmd5 for Redwood
Building amd_md5md5 for Cypress
Building amd_md5_saltpass for Cypress
Building amd_lm for ATI RV710
Building amd_ipb2_long for ATI RV710
Building amd_pixmd5_long for Cypress
Building amd_sha1_long for ATI RV710

however it is nothing compared to the verbosity of the nvidia builds:

x86_64-pc-linux-gnu-gcc -DPACKAGE_NAME="hashkill" -DPACKAGE_TARNAME="hashkill" -DPACKAGE_VERSION="0.3.1" -DPACKAGE_STRING="hashkill\ 0.3.1" -DPACKAGE_BUGREPORT="[email protected]" -DPACKAGE_URL="" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" -DPACKAGE="hashkill" -DVERSION="0.3.1" -DHAVE_TERMIOS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_FCNTL_H=1 -DHAVE_STDLIB_H=1 -DHAVE_PTHREAD_H=1 -DHAVE_DLFCN_H=1 -DHAVE_STRING_H=1 -DHAVE_UNISTD_H=1 -DHAVE_OPENSSL_MD5_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_ZLIB_H=1 -DHAVE_WCHAR_H=1 -DHAVE_STDDEF_H=1 -DHAVE_PTRDIFF_T=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DHAVE_BZERO=1 -DHAVE_STRSTR=1 -DHAVE_SYSINFO=1 -DHAVE_STRERROR=1 -DHAVE_ENDPWENT=1 -DHAVE_GETCWD=1 -DHAVE_STRCHR=1 -DHAVE_STRCSPN=1 -DHAVE_STRTOUL=1 -DHAVE_MEMSET=1 -DHAVE_STRTOL=1 -DHAVE_ATEXIT=1 -DHAVE_MEMMOVE=1 -DHAVE_MKDIR=1 -DHAVE_MUNMAP=1 -DHAVE_SETENV=1 -DHAVE_MEMCHR=1 -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_ALLOCA_H=1 -DHAVE_ALLOCA=1 -DLSTAT_FOLLOWS_SLASHED_SYMLINK=1 -DHAVE_SSE2=/**/ -I. -msse2 -DHAVE_JSON_JSON_H -fPIC -O3 -fomit-frame-pointer -momit-leaf-frame-pointer -Wall -Wno-format -ftree-vectorize -DBINDIR="/usr/bin" -DDATADIR="/usr/share" -pthread -Wno-unused-value -Wno-unused-result -Wno-switch -D_7ZIP_ST -flto -fwhole-program -Wno-psabi -Os -march=native -pipe -c -o hashkill-ocl_odf.o test -f 'ocl_odf.c' || echo './'ocl_odf.c
ocl_pdf.c: In function 'ocl_rule_pdf_thread':
ocl_pdf.c:601:2: warning: 'return' with no value, in function returning non-void [-Wreturn-type]

I know it's ugly in the bugzie, but this kind of output is far more useful for determining what is going wrong at different stages of the compile.

is there any way to bring them closer together? it would be nice to see the exact commands running so that it is easier to troubleshoot errors, etc.

[gat3way]

This is very strange...the verbose output is not from nvidia kernels I think....ocl_odf.c is the host CPU code. I am confused...

[ZeroChaos-]

now see, that could totally be my misunderstanding then... checking

[ZeroChaos-]

it seems that despite me telling it to build for nvidia that it is refusing:

Could not find an NVidia platform. Exiting.

In the end that all scrolls by so fast that I only notice the cpu code being built.

As far as this bug is concerned though, I would prefer the amd/ati build look more like the cpu build.

[gat3way]

I don't think that's quite possible...one is produced by automake, the other is produced by the amd-compiler (which has nothing to do with what automake does)

[ZeroChaos-]

it hurts you more than me as you can't really see useful output of how things are compiling in bug reports. if there is nothing you can do here the close the bug and we will both accept the facts.

[gat3way]

Well it's my mistake, I did not explain it well. Definitely, kernel compilation can be made more verbose. But it cannot follow the same output as the one produced by automake when building host .c sources. Reason is that most of that output is irrelevant to the kernel build process, e.g the defines like -DHAVE_BZERO=1... have no influence on kernel compilation and since we're not using gcc, gcc-specific options like -flto -fwhole-program.... also have no meaning to the kernel compilation process. So yes - I can (and will) make kernel compilation more verbose. But at the same time no - it can't look like the same as the one produced by automake when compiling host code, because they are different things.

[ZeroChaos-]

heh. When I said "look the same" I meant "show the full compiler command line" not identical to gcc ;-) New versions of the toolkits etc may have an effect on what flags are pushed to the compiler and you may need it for troubleshooting is all.

[gat3way]

Could you check if the verbosity is OK for you with the latest commit?

[ZeroChaos-]

For my purposes, the verbosity you started with was okay. My point is that when users come to you with build issues you may wish for more output than is available. Your output is better for sure, but I can't persaonlly say it's anywhere near as useful for debugging as the output from gcc.

amd_oracle_old_long: building for Juniper
amd_oracle_old_long: flags = -fno-bin-amdil -fno-bin-llvmir -fno-bin-source
amd_oracle_old_long: compilation for Juniper successful (size = 5070 KB)
amd_oracle_old_long: compressed Juniper kernel (compressed size = 185 KB)

This bug is for you, you may close if you like. It really doesn't affect me or my users in any way, it only really affects you when users (like me) report bugs (like amd-compiler randomly segfaulting) and you may not have all the info you could have to solve it.

[gat3way]

I see. Well, I think I have a different problem here. With introduction of parallel jobs (-jX) output gets really mixed and more verbosity would not help significantly. You can have a failing compilation followed by successful ones before the whole make fails. Right now I don't have a good solution though, except for probably creating an error log file per kernel compilation. This is something that I need to analyze further. For now, I will keep that thread open.