Error on building ttman.o

[The GZeus]

The following error on building the latest git
make clean; make
...
HOSTCC Doc/ttman.o
/bin/sh: -c: not found
make: *** [Doc/ttman.o] Error 127

debian testing

[Jason Woofenden]

Post by The GZeus
The following error on building the latest git
make clean; make
...
HOSTCC Doc/ttman.o
/bin/sh: -c: not found
make: *** [Doc/ttman.o] Error 127
debian testing

Hey all,

Can we please stop hiding the build commands by default? I don't
see much value in the compile output being "prettier", and it's
obviously makes it more difficult for folks to figure out what went
wrong. Trivial patch attached.


The GZeus,

Here's how you can see the command that's failing:

make V=2

Please write us again if you need further assistance, or if you
think there might be something we can do to help make this not
happen for other people.

Take care, - Jason

[Gregory Petrosyan]

Hi Jason,

Post by Jason Woofenden
Can we please stop hiding the build commands by default? I don't
see much value in the compile output being "prettier", and it's
obviously makes it more difficult for folks to figure out what went
wrong. Trivial patch attached.

I have to disagree: compiler output being prettier is very important
not only from aesthetic point of view, but it makes every error or
warning during the compilation really stand out. IMO V=1 is a much
better default.

                Gregory

[Jason Woofenden]

Post by Gregory Petrosyan
Hi Jason,

Post by Jason Woofenden
Can we please stop hiding the build commands by default? I don't
see much value in the compile output being "prettier", and it's
obviously makes it more difficult for folks to figure out what went
wrong. Trivial patch attached.

I have to disagree: compiler output being prettier is very important
not only from aesthetic point of view, but it makes every error or
warning during the compilation really stand out. IMO V=1 is a much
better default.

Ahh, that is useful. I hadn't thought of that.

My preference is to leave it verbose by default and add -Werror to
the compile flags. Has this been considered/discussed?

cmus compiles fine on my desktop with CFLAGS="-ggdb -Wall -Werror".
Though there may

I do get warnings on my laptop though, I'll mail those separately.

Take care, - Jason

[Gregory Petrosyan]

Post by Jason Woofenden
My preference is to leave it verbose by default and add -Werror to
the compile flags. Has this been considered/discussed?

I don't think -Werror is a good fit for cmus, since it is used on a
lot of architectures, and is built with lots of compilers. We can't
guarantee an absence of warnings on all of them, so -Werror will
inevitably result in lots of needless compile failures.

For "one platform, one compiler" projects -Werror can be good, though.

                Gregory

[e***@cs.umn.edu]

I would prefer it if compilation was as quiet as possible,
then exploded with information when it failed. I like the status
updates as it goes though.

Is there a way for it to be extra verbose when it fails?

Post by Jason Woofenden

Post by Gregory Petrosyan
Hi Jason,

Post by Jason Woofenden
Can we please stop hiding the build commands by default? I don't
see much value in the compile output being "prettier", and it's
obviously makes it more difficult for folks to figure out what went
wrong. Trivial patch attached.

I have to disagree: compiler output being prettier is very important
not only from aesthetic point of view, but it makes every error or
warning during the compilation really stand out. IMO V=1 is a much
better default.

Ahh, that is useful. I hadn't thought of that.
My preference is to leave it verbose by default and add -Werror to
the compile flags. Has this been considered/discussed?
cmus compiles fine on my desktop with CFLAGS="-ggdb -Wall -Werror".
Though there may
I do get warnings on my laptop though, I'll mail those separately.
Take care, - Jason
------------------------------------------------------------------------------
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb

[Johannes Weißl]

Hello Jason,

Post by Jason Woofenden

Post by Gregory Petrosyan

Post by Jason Woofenden
Can we please stop hiding the build commands by default? I don't
see much value in the compile output being "prettier", and it's
obviously makes it more difficult for folks to figure out what went
wrong. Trivial patch attached.

I have to disagree: compiler output being prettier is very important
not only from aesthetic point of view, but it makes every error or
warning during the compilation really stand out. IMO V=1 is a much
better default.

Ahh, that is useful. I hadn't thought of that.
My preference is to leave it verbose by default and add -Werror to
the compile flags. Has this been considered/discussed?
cmus compiles fine on my desktop with CFLAGS="-ggdb -Wall -Werror".
Though there may

I'm in favor for hiding the compile output by default, for the same
reasons Gregory gave. Also adding -Werror is problematic, since nobody
can guarantee that there aren't any compile warnings in future/different
compilers. Warnings are not errors, building cmus should not fail
because of them.

Maybe ./configure could print something like "use make V=2 for full
output"? Also, I think cmus configure script had a nice list of
enabled/disabled features/plugins at the end (like mplayer) in v2.0.0,
why don't we introduce it again?


Johannes

[Jason Woofenden]

I'm running the debian unstable (mipsel port) on my lemote.

I tried building cmus (pu branch) just now with -Werror just now,
and it stops with the warnings below. Attached is the full verbose
output of ./configure && make V=2 -j2


gcc -c -ggdb -Wall -Werror -std=gnu99 -pipe -Wall -Wshadow -Wcast-align -Wpointer-arith -Wwrite-strings -Wundef -Wmissing-prototypes -Wredundant-decls -Wextra -Wno-sign-compare -Wformat-security -Wdeclaration-after-statement -Wold-style-definition -Wno-pointer-sign -Werror-implicit-function-declaration -Wno-unused-parameter -MMD -MP -MF .dep-browser.o -DREALTIME_SCHEDULING -D_FILE_OFFSET_BITS=64 -D_REENTRANT -o browser.o browser.c
cc1: warnings being treated as errors
browser.c: In function 'free_browser_list':
browser.c:113: error: cast increases required alignment of target type
browser.c: In function 'do_browser_load':
browser.c:192: error: cast increases required alignment of target type
browser.c: In function 'browser_get_prev':
browser.c:226: error: cast increases required alignment of target type
browser.c:226: error: cast increases required alignment of target type
browser.c: In function 'browser_get_next':
browser.c:227: error: cast increases required alignment of target type
browser.c:227: error: cast increases required alignment of target type
browser.c: In function 'browser_up':
browser.c:341: error: cast increases required alignment of target type
browser.c:341: error: cast increases required alignment of target type
browser.c: In function 'browser_reload':
browser.c:476: error: cast increases required alignment of target type
browser.c:476: error: cast increases required alignment of target type
make: *** [browser.o] Error 1


I don't think I know enough about this stuff to fix it myself.

Please let me know if I can dig up additional info or experiment or
something.

Take care, - Jason

[Gregory Petrosyan]

Post by Jason Woofenden
I'm running the debian unstable (mipsel port) on my lemote.
I tried building cmus (pu branch) just now with -Werror just now,
and it stops with the warnings below. Attached is the full verbose
output of ./configure && make V=2 -j2
  gcc -c -ggdb -Wall -Werror   -std=gnu99 -pipe -Wall -Wshadow -Wcast-align -Wpointer-arith -Wwrite-strings -Wundef -Wmissing-prototypes -Wredundant-decls -Wextra -Wno-sign-compare -Wformat-security -Wdeclaration-after-statement -Wold-style-definition -Wno-pointer-sign -Werror-implicit-function-declaration -Wno-unused-parameter -MMD -MP -MF .dep-browser.o -DREALTIME_SCHEDULING -D_FILE_OFFSET_BITS=64 -D_REENTRANT    -o browser.o browser.c
cc1: warnings being treated as errors
browser.c:113: error: cast increases required alignment of target type

It seems that this warning is totally harmless:

list_entry expands to container_of, which contains (type*)((char*)ptr1
- ptr2) cast, which seems to annoy GCC (since type* has more alignment
requirements then char* on the target platform, I guess).

If linux kernel has an updated version of container_of, which does not
trigger the warning, we can borrow it. Otherwise, we can make fun of
GCC, compile without -Werror and be happy :-)

                Gregory

[Johannes Weißl]

Post by Gregory Petrosyan

Post by Jason Woofenden
I'm running the debian unstable (mipsel port) on my lemote.
I tried building cmus (pu branch) just now with -Werror just now,
and it stops with the warnings below. Attached is the full verbose
output of ./configure && make V=2 -j2
  gcc -c -ggdb -Wall -Werror   -std=gnu99 -pipe -Wall -Wshadow -Wcast-align -Wpointer-arith -Wwrite-strings -Wundef -Wmissing-prototypes -Wredundant-decls -Wextra -Wno-sign-compare -Wformat-security -Wdeclaration-after-statement -Wold-style-definition -Wno-pointer-sign -Werror-implicit-function-declaration -Wno-unused-parameter -MMD -MP -MF .dep-browser.o -DREALTIME_SCHEDULING -D_FILE_OFFSET_BITS=64 -D_REENTRANT    -o browser.o browser.c
cc1: warnings being treated as errors
browser.c:113: error: cast increases required alignment of target type

list_entry expands to container_of, which contains (type*)((char*)ptr1
- ptr2) cast, which seems to annoy GCC (since type* has more alignment
requirements then char* on the target platform, I guess).
If linux kernel has an updated version of container_of, which does not
trigger the warning, we can borrow it. Otherwise, we can make fun of
GCC, compile without -Werror and be happy :-)

Hmm, I started qemu running emulated Debian 6.0, and I can confirm the
warning. It really seems to be a false positive, but the Linux kernel
contains no updated version:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/linux/kernel.h;hb=HEAD#l551

I found a fix [1] by the openvswitch.org project which silences the
warning. It should be harmless since (void *) can store any pointer.
Patch is attached! What do you think? The generated object files are
identical...

[1] http://openvswitch.org/pipermail/dev_openvswitch.org/2010-May/001995.html


Johannes

[The GZeus]

looks like the error was in front of the keyboard
./configure
make
...

works

Fail.