Summary: | dev-lang/erlang-15.2.2 - In file included from beam/sys.h:47:0, from hipe/hipe_mkliterals.c:29: sys/unix/erl_unix_sys.h:177:1: error: unknown type name ‘hrtime_t’ | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Craig Andrews <candrews> |
Component: | New packages | Assignee: | Dirkjan Ochtman (RETIRED) <djc> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | aranea, billiob, candrews, lang-misc+disabled |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build log
kernel-config-x86_64-3.6.0-gentoo config.log |
Description
Craig Andrews
2012-10-08 00:19:20 UTC
Created attachment 325962 [details]
build log
x86_64-pc-linux-gnu-gcc -O3 -march=native -pipe -fomit-frame-pointer -flto -I/var/tmp/portage/dev-lang/erlang-15.2.2/work/otp_src_R15B02/erts/x86_64-pc-linux-gnu -fno-tree-copyrename -D_GNU_SOURCE -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -DPOSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTIONS -Ix86_64-pc-linux-gnu/opt/plain -Ibeam -Isys/unix -Isys/common -Ix86_64-pc-linux-gnu -Ipcre -Ihipe -I../include -I../include/x86_64-pc-linux-gnu -I../include/internal -I../include/internal/x86_64-pc-linux-gnu -c hipe/hipe_mkliterals.c -o obj/x86_64-pc-linux-gnu/opt/plain/hipe_mkliterals.o In file included from beam/sys.h:47:0, from hipe/hipe_mkliterals.c:29: sys/unix/erl_unix_sys.h:177:1: error: unknown type name ‘hrtime_t’ make[2]: *** [obj/x86_64-pc-linux-gnu/opt/plain/hipe_mkliterals.o] Error 1 Could you please paste the line written during configure about "checking how to correct for time adjustments..." ? (In reply to comment #3) > Could you please paste the line written during configure about "checking how > to correct for time adjustments..." ? checking how to correct for time adjustments... hrtime I attached the build log, too. "checking for gethrtime... yes" seems strange. Are you using realtime linux? Could you try to compile the following C code (just gcc tmp.c) ? int main() { gethrtime(); return 0; } (In reply to comment #5) > "checking for gethrtime... yes" seems strange. > Are you using realtime linux? > Could you try to compile the following C code (just gcc tmp.c) ? > int main() > { > gethrtime(); > return 0; > } $ gcc tmp.c /tmp/cc2UCBEe.o: In function `main': test.c:(.text+0xa): undefined reference to `gethrtime' collect2: error: ld returned 1 exit status I didn't expect that. I'm not running real time linux - I'm using 3.6.0-gentoo. I'm attaching my .config Created attachment 326136 [details]
kernel-config-x86_64-3.6.0-gentoo
Couldn't reproduce this, neither with hardened-sources-3.5.4-r1 nor with gentoo-sources-3.6.0. In both cases, I get checking for gethrtime... no checking how to correct for time adjustments... clock_gettime instead of your checking for gethrtime... yes checking how to correct for time adjustments... hrtime There really seems to be some black autotools magic involved here... Could you attach the config.log? Created attachment 326200 [details]
config.log
This is /var/tmp/portage/dev-lang/erlang-15.2.2/work/otp_src_R15B02/config.log
This problem is reproducible with: CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer -flto" LDFLAGS="${LDFLAGS} -flto" As well as with: CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer -flto -fno-lto" LDFLAGS="${LDFLAGS} -flto -fno-lto" However, the problem does not occur with: CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer" LDFLAGS="${LDFLAGS}" As I understand it, "-flto -fno-lto" should be equivalent to "", so 2 and 3 above should have the same behavior. But they don't! Looks like a gcc bug. If you take the following piece of code (as conftest.c): #include <limits.h> char gethrtime (); char (*f) () = gethrtime; int main () { return f != gethrtime; } then, 'cc -o conftest conftest.c -flto' will produce an error as expected while 'cc -o bite -O2 bite.c -flto' will not. Boris, perhaps you can file a gcc bug? Closing this as UPSTREAM. It's not a bug in gcc itself. It was a bug in autoconf-2.59 that upstream use to generate its configure. I couldn't reproduce the issue after doing an "autoreconf" with autoconf-2.69. Should it be added to the ebuild? |