cannot configure libogg #264

Open
paleozogt opened this Issue Feb 20, 2012 · 22 comments

Projects

None yet

6 participants

@paleozogt

I'm trying to build libogg. When I run configure it errors with No 16 bit type found on this platform!

Here's the command and full configure output:

$ emconfigure ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for gcc... /home/bobthebuilder/Development/emscripten/emcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether /home/bobthebuilder/Development/emscripten/emcc accepts -g... yes
checking for /home/bobthebuilder/Development/emscripten/emcc option to accept ISO C89... none needed
checking for style of include used by make... GNU
checking dependency style of /home/bobthebuilder/Development/emscripten/emcc... gcc3
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by /home/bobthebuilder/Development/emscripten/emcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert i686-pc-linux-gnu file names to i686-pc-linux-gnu format... func_convert_file_noop
checking how to convert i686-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for archiver @FILE support... no
checking for strip... strip
checking for ranlib... /home/bobthebuilder/Development/emscripten/emranlib
checking command to parse /usr/bin/nm -B output from /home/bobthebuilder/Development/emscripten/emcc object... ok
checking for sysroot... no
checking for mt... mt
checking if mt is a manifest tool... no
checking how to run the C preprocessor... /home/bobthebuilder/Development/emscripten/emcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if /home/bobthebuilder/Development/emscripten/emcc supports -fno-rtti -fno-exceptions... yes
checking for /home/bobthebuilder/Development/emscripten/emcc option to produce PIC... -fPIC -DPIC
checking if /home/bobthebuilder/Development/emscripten/emcc PIC flag -fPIC -DPIC works... yes
checking if /home/bobthebuilder/Development/emscripten/emcc static flag -static works... yes
checking if /home/bobthebuilder/Development/emscripten/emcc supports -c -o file.o... yes
checking if /home/bobthebuilder/Development/emscripten/emcc supports -c -o file.o... (cached) yes
checking whether the /home/bobthebuilder/Development/emscripten/emcc linker (/usr/bin/ld) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether /home/bobthebuilder/Development/emscripten/emcc and cc understand -c and -o together... yes
checking for ANSI C header files... (cached) yes
checking for inttypes.h... (cached) yes
checking for stdint.h... (cached) yes
checking for sys/types.h... (cached) yes
checking for an ANSI C-conforming const... no
checking size of int16_t... 0
checking size of uint16_t... 0
checking size of u_int16_t... 0
checking size of int32_t... 0
checking size of uint32_t... 0
checking size of u_int32_t... 0
checking size of int64_t... 0
checking size of short... 0
checking size of int... 0
checking size of long... 0
checking size of long long... 0
configure: error: No 16 bit type found on this platform!
@kripken
Owner
kripken commented Feb 20, 2012

There should be a config.log file or such that configure generates, that has the file it compiled and the error it got, that led to the error message there. Please pastebin that. Hopefully the issue is something easily fixable.

@paleozogt

Here you go: config.log

@kripken
Owner
kripken commented Feb 21, 2012

This looks like a gcc/clang issue. The failure that makes it abort compiles fine with gcc, but fails with clang. The error is

  clang -o conftest -O20 -Wall -ffast-math -fsigned-char    conftest.c
  error: invalid value '4' in '-O20'

gcc accepts -O20 (and ignores it I assume). It might be worth reporting this to the clang devs since I am not sure if gcc or clang is wrong here.

As a workaround, you can modify the configure script to not use -O20 (why is that even there?), use -O2 instead. Or, we can add an option to emcc to use gcc instead of clang when just configuring (search for EMMAKEN_JUST_CONFIGURE).

@paleozogt

btw, I tried it on mac and while the console output looks the same, the config.log is completely different. I've uploaded it here.

@paleozogt

Ah, you're right about the clang issue. Trying directly also shows the error.

@paleozogt

Weirdly, using clang for configuring (on unix) works:

$export CC=clang
$export CXX=clang++
$./configure
creating cache ./config.cache
checking for a BSD compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets ${MAKE}... yes
checking for working aclocal... found
checking for working autoconf... found
checking for working automake... found
checking for working autoheader... found
checking for working makeinfo... found
checking for gcc... clang
checking whether the C compiler (clang  ) works... yes
checking whether the C compiler (clang  ) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether clang accepts -g... yes
checking for Cygwin environment... no
checking for mingw32 environment... no
checking how to run the C preprocessor... clang -E
checking host system type... x86_64-unknown-linux-gnu
checking build system type... x86_64-unknown-linux-gnu
checking for ld used by GCC... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for /usr/bin/ld option to reload object files... -r
checking for BSD-compatible nm... /usr/bin/nm -B
checking for a sed that does not truncate output... /bin/sed
checking whether ln -s works... yes
checking how to recognise dependent libraries... file_magic ELF [0-9][0-9]*-bit [LM]SB (shared object|dynamic lib )
checking for object suffix... o
checking for executable suffix... no
checking command to parse /usr/bin/nm -B output... ok
checking for dlfcn.h... yes
checking for file... /usr/bin/file
checking for ranlib... ranlib
checking for strip... strip
checking for objdir... .libs
checking for clang option to produce PIC... -fPIC
checking if clang PIC flag -fPIC works... yes
checking if clang static flag -static works... yes
checking if clang supports -c -o file.o... yes
checking if clang supports -c -o file.lo... yes
checking if clang supports -fno-rtti -fno-exceptions... yes
checking whether the linker (/usr/bin/ld) supports shared libraries... yes
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking dynamic linker characteristics... GNU/Linux ld.so
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking whether -lc should be explicitly linked in... no
creating libtool
checking for ANSI C header files... yes
checking for working const... yes
checking for int16_t... yes
checking for int32_t... yes
checking for uint32_t... no
checking for u_int32_t... yes
checking for int64_t... yes
checking size of short... 2
checking size of int... 4
checking size of long... 8
checking size of long long... 8
checking for 8-bit clean memcmp... yes
updating cache ./config.cache
creating ./config.status
creating Makefile
creating src/Makefile
creating doc/Makefile
creating doc/ogg/Makefile
creating include/Makefile
creating include/ogg/Makefile
creating include/ogg/config_types.h
creating win32/Makefile
creating debian/Makefile
$

The config.log is here. The command its using still has O20, but also has O2 (??) which seems to make clang happy:
clang -o conftest -O20 -ffast-math -fsigned-char -g -O2 conftest.c 1>&5

@paleozogt

I've filed a bug with clang here.

@paleozogt

@kripken I've been able to work around the -O20 problem by editing the configure file, as you suggested. :) However, on mac its failing for completely different reasons (see config.log).

@kripken
Owner
kripken commented Feb 21, 2012

? I see the same error: invalid value '4' in '-O20' in that log as well.

@paleozogt

I think you might be looking at the wrong config.log. Here's a link to it on its [own page](https://raw.github.com/gist/1869963/efbc73cd1c5946df529b5e6e42e054e8845466f8/config.log%20(mac%20os%20x).

@kripken
Owner
kripken commented Feb 21, 2012

Oh ok, sorry.

Linker errors in there, it seems? Do you get them on that machine when you run the command directly too?

@LeesTimeDotCom

BTW: On my Ubuntu 11.04 32bit, If I replace all occurrences of -O20 with -O2 or -O3, it's working. but -O4 is NOT working.

@povrazor

@peterleecomcn GCC technically doesn't support -O4. It instead treats it as -O3.

http://stackoverflow.com/questions/3399821/gcc-o4-optimization-flag
http://www.gentoo.org/doc/en/gcc-optimization.xml

Clang is less graceful about optimizations above 3, reporting the error mentioned above (error: invalid value '4' in '-O20').

@kripken
Owner
kripken commented Jul 12, 2012

If the only issue is clang not liking -O4+, i think we can close this. If there are other open things here please comment.

@kripken kripken closed this Jul 12, 2012
@chrismcr

I'm getting the second issue @paleozogt mentioned, on os x. During the configure scripts 'checking size of [data type]...' phase, every test fails with the same error: https://gist.github.com/chrismcr/5490366

@kripken
Owner
kripken commented Apr 30, 2013

Can you try to configure it with EMCONFIGURE_JS=1 in the environment, on the incoming branch? That runs configure tests in js and not natively.

@chrismcr

That gets me an error about /lib/cpp (which doesn't exist) - https://gist.github.com/chrismcr/5490551

@chrismcr

If I force CPP=/usr/bin/cpp, I get the same linker errors as before. I am seeing references to conftest.js in certain places though so it appears EMCONFIGURE_JS is being set.

@kripken kripken reopened this May 1, 2013
@kripken
Owner
kripken commented May 1, 2013

Ok, can you give me full steps to reproduce and i'll try this locally?

@chrismcr
chrismcr commented May 1, 2013

Sure - it's just a straight emconfigure ./configure => "No 16 bit type found on this platform!"

Out of interest, I've checked the config.log after setting EMCONFIGURE_JS again, and the "checking size..." tests are definitely still native, when earlier tests are js.

@kripken
Owner
kripken commented May 2, 2013

It looks like EMCONFIGURE_JS won't help since the specific test does file io (so we need to use a native executable).

I don't know enough about configure scripts to debug this. I can see the failing program in config.log, but not sure why it prints out that error message, looks like the variable for 16-bit is not set. Anyone here an autotools person? ;)

@kripken kripken closed this May 2, 2013
@kripken kripken reopened this May 2, 2013
@trinacriax

Let me share my experience.
I had the same problem
$ emconfigure ./configure --prefix=/home/test/libogg-install

checking size of u_int16_t... 0
checking size of int32_t... 0
checking size of uint32_t... 0
checking size of u_int32_t... 0
checking size of int64_t... 0
checking size of short... 0
checking size of int... 0
checking size of long... 0
checking size of long long... 0
configure: error: No 16 bit type found on this platform!

config.log showed an invalid value

error: invalid value '20' in '-O20'

thus, I changed it and...

$ sed -i "s/-O20/-O2/g" configure 
$ emconfigure ./configure --prefix=/home/test/libogg-install 

...it worked.

@brion brion added a commit to brion/emscripten that referenced this issue Oct 31, 2014
@brion brion Accept -O4 and larger values, clamping to 3 and warning
GCC and clang accept huge -O* values like -O4 and -O20, silently
clamping them to a sensible -O3. Some packages rely on this and
specify -O20 as a default "REALLY FAST", such as libogg and libvorbis.

For compatibility, accept the large values, clamp them to 3, and
print a warning instead of throwing and exception and dying.

Fixes kripken#1499
Fixes kripken#264
35db825
@brion brion added a commit to brion/emscripten that referenced this issue Nov 1, 2014
@brion brion Accept -O4 and larger values, clamping to 3 and warning
GCC and clang accept huge -O* values like -O4 and -O20, silently
clamping them to a sensible -O3. Some packages rely on this and
specify -O20 as a default "REALLY FAST", such as libogg and libvorbis.

For compatibility, accept the large values, clamp them to 3, and
print a warning instead of throwing an exception and dying.

Fixes kripken#1499
Fixes kripken#264
f61895a
@brion brion added a commit to brion/emscripten that referenced this issue Aug 24, 2015
@brion brion Accept -O4 and larger values, clamping to 3 and warning
GCC and clang accept huge -O* values like -O4 and -O20, silently
clamping them to a sensible -O3. Some packages rely on this and
specify -O20 as a default "REALLY FAST", such as libogg and libvorbis.

For compatibility, accept the large values, clamp them to 3, and
print a warning instead of throwing an exception and dying.

Test case added.

Fixes kripken#1499
Fixes kripken#264
52f3d56
@brion brion added a commit to brion/emscripten that referenced this issue Aug 24, 2015
@brion brion Accept -O4 and larger values, clamping to 3 and warning
GCC and clang accept huge -O* values like -O4 and -O20, silently
clamping them to a sensible -O3. Some packages rely on this and
specify -O20 as a default "REALLY FAST", such as libogg and libvorbis.

For compatibility, accept the large values, clamp them to 3, and
print a warning instead of throwing an exception and dying.

Test case added.

Fixes kripken#1499
Fixes kripken#264
1f71038
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment