The F-13 (rawhide) build broke because %configure now uses --disable-dependency-tracking and that did not work with our Makefile.am hooey.
In fixing it, I consolidated all the manual duplication into config/eu.am, a new automake include file. Things are not all exactly as they were before, because there is more uniformity across the subdirectories.
I think I made everything come out the way it should. I tested make and make check for --enable-{gcov,gprof,mudflap} as well as the vanilla build. They don't seem to have been broken. The mudflap build's check stage is full of fail, but that does not seem to be new.
Please poke, review, and complain if I broke anything.
Thanks, Roland
On Mon, 2010-02-15 at 16:14 -0800, Roland McGrath wrote:
Please poke, review, and complain if I broke anything.
Works for me on x86_64 & i386, both with builddir == srcdir and builddir != srcdir, with and without --disable-dependency-tracking.
I did have to make one little tweak to the systemtap embedded elfutils build infrastructure. But that is because we only do a partial build/install in that case, bypassing some of the normal make targets. Yeah it is messy, we really should just encourage people to install elfutils normally.
It would be nice to have a formal 0.145 release with this and the other bug fixes since 0.144.
Thanks,
Mark
I did have to make one little tweak to the systemtap embedded elfutils build infrastructure. But that is because we only do a partial build/install in that case, bypassing some of the normal make targets.
That is odd. I don't think the behavior of any make targets should have changed. Can you elaborate on this problem?
It would be nice to have a formal 0.145 release with this and the other bug fixes since 0.144.
Yes, I plan to have one fairly soon. I was thinking maybe the end of the week. We won't get it done before the F-13 branching (starting in two hours from this writing), but it won't be any problem this week or next to put 0.145 in F-13 anyway.
Aside from any more build nit shake-out, I'd like to see if Petr and I can hunt down some crashes in core file support that keep making abrt file bugs (about eu-unstrip crashing while abrt tries to examine the core dump from something else crashing!). We finally have a local reproducer case, so we should get a fix or two in soon. That's the only thing I know of for which 0.145 is waiting.
Thanks, Roland
On Tue, 2010-02-16 at 14:11 -0800, Roland McGrath wrote:
I did have to make one little tweak to the systemtap embedded elfutils build infrastructure. But that is because we only do a partial build/install in that case, bypassing some of the normal make targets.
That is odd. I don't think the behavior of any make targets should have changed. Can you elaborate on this problem?
It might be broken before. And I wouldn't worry too much about it. The systemtap build only supports is for older distros that need some of the elfutils libs includes in the systemtap install itself. Basically when you use --with-elfutils=/path/to/elfutils/src the configure will do:
# Our libdw.so's libebl will look in $ORIGIN/../lib/... but that # $ORIGIN is where libdw.so resides, which is not where there is a ../lib. # Note that $libdir might be using a quoted use of $exec_prefix or $prefix. # So we must make sure to pass those settings to elfutils configure. elfutils_rpath="-Wl,--enable-new-dtags,-rpath,${libdir}/${PACKAGE_NAME}" here=`pwd` (mkdir -p build-elfutils && cd build-elfutils && bash ${elfutils_srcdir}/configure --enable-libebl-subdir=${PACKAGE_NAME} \ --includedir="${here}/include-elfutils" \ --libdir="${here}/lib-elfutils" \ --exec-prefix="$exec_prefix" \ --prefix="$prefix" \ CFLAGS="${CFLAGS/-Wall/} $gnu89_inline_flag" \ LDFLAGS="$LDFLAGS $elfutils_rpath" && if test -f ${elfutils_srcdir}/config/version.h.in; then echo Trying to install elfutils version header... make install-pkgincludeHEADERS fi # so that elfutils/version.h - available from 0.138 - may be found. # Don't use install-data because that will fail (installing in $prefix). ) if test $? != 0; then exit; fi save_CPPFLAGS=${CPPFLAGS} CPPFLAGS="${CPPFLAGS} -Iinclude-elfutils" # in case bundled elfutils AC_CHECK_HEADERS([elfutils/version.h]) CPPFLAGS="$save_CPPFLAGS"
Note that one make target is done early during the configure step to get access to the version.h header. Then during the make step we do:
if BUILD_ELFUTILS stap_CPPFLAGS += -Iinclude-elfutils stap_LDFLAGS += -Llib-elfutils -Wl,-rpath-link,lib-elfutils \ -Wl,--enable-new-dtags,-rpath,$(pkglibdir)
BUILT_SOURCES += stamp-elfutils CLEANFILES += stamp-elfutils stamp-elfutils: config.status $(MAKE) $(AM_MAKEFLAGS) -C build-elfutils all bin_PROGRAMS= for dir in libelf libebl libdw libdwfl backends; do \ $(MAKE) $(AM_MAKEFLAGS) -C build-elfutils/$$dir bin_PROGRAMS= install; \ done touch $@ stap_DEPENDENCIES += lib-elfutils/libdw.so lib-elfutils/libdw.so: stamp-elfutils ;
Note how we are using bin_PROGRAMS= and only doing an install in the separate build directories. This last step goes wrong when we are running parallel make with -j BIG. Then sometimes you will get:
ranlib libebl_ppc64_pic.a rm -f libebl_s390_pic.a ar cru libebl_s390_pic.a s390_init.os s390_symbol.os s390_regs.os s390_retval.os ar cru libebl_s390_pic.a s390_init.os s390_symbol.os s390_regs.os s390_retval.os echo 'ELFUTILS_0.144 { global: i386_init; local: *; };' > libebl_i386.map ranlib libebl_arm_pic.a echo 'ELFUTILS_0.144 { global: sh_init; local: *; };' > libebl_sh.map ranlib libebl_ppc_pic.a echo 'ELFUTILS_0.144 { global: x86_64_init; local: *; };' > libebl_x86_64.map ranlib libebl_sparc_pic.a ranlib libebl_s390_pic.a echo 'ELFUTILS_0.144 { global: ia64_init; local: *; };' > libebl_ia64.map echo 'ELFUTILS_0.144 { global: alpha_init; local: *; };' > libebl_alpha.map echo 'ELFUTILS_0.144 { global: ppc64_init; local: *; };' > libebl_ppc64.map gcc -std=gnu99 -Wall -Wshadow -Werror -Wunused -Wextra -Wformat=2 -g -O2 -fstack-protector-all -D_FORTIFY_SOURCE=2 -fgnu89-inline -Wl,--enable-new-dtags,-rpath,/usr/local/install/systemtap/lib/systemtap -o libebl_i386.so -shared -o libebl_i386.so -Wl,--whole-archive,libebl_i386_pic.a\ ../libcpu/libcpu_i386.a -Wl,--no-whole-archive \ -Wl,--version-script,libebl_i386.map \ -Wl,-z,defs -Wl,--as-needed ../libelf/libelf.so ../libdw/libdw.so [... a couple of other gcc invocations using other arches ...] gcc -std=gnu99 -Wall -Wshadow -Werror -Wunused -Wextra -Wformat=2 -g -O2 -fstack-protector-all -D_FORTIFY_SOURCE=2 -fgnu89-inline -Wl,--enable-new-dtags,-rpath,/usr/local/install/systemtap/lib/systemtap -o libebl_ppc.so -shared -o libebl_ppc.so -Wl,--whole-archive,libebl_ppc_pic.a\ -Wl,--no-whole-archive \ -Wl,--version-script,libebl_ppc.map \ -Wl,-z,defs -Wl,--as-needed ../libelf/libelf.so ../libdw/libdw.so gcc -std=gnu99 -Wall -Wshadow -Werror -Wunused -Wextra -Wformat=2 -g -O2 -fstack-protector-all -D_FORTIFY_SOURCE=2 -fgnu89-inline -Wl,--enable-new-dtags,-rpath,/usr/local/install/systemtap/lib/systemtap -o libebl_s390.so -shared -o libebl_s390.so -Wl,--whole-archive,libebl_s390_pic.a\ -Wl,--no-whole-archive \ -Wl,--version-script,libebl_s390.map \ -Wl,-z,defs -Wl,--as-needed ../libelf/libelf.so ../libdw/libdw.so /usr/bin/ld: cannot open linker script file libebl_ppc.map: No such file or directory collect2: ld returned 1 exit status make[1]: *** [libebl_ppc.so] Error 1 make[1]: *** Waiting for unfinished jobs.... /usr/bin/ld: cannot open linker script file libebl_s390.map: No such file or directory collect2: ld returned 1 exit status make[1]: *** [libebl_s390.so] Error 1 /usr/bin/ld: cannot open linker script file libebl_arm.map: No such file or directory collect2: ld returned 1 exit status make[1]: *** [libebl_arm.so] Error 1 if readelf -d libebl_sh.so | fgrep -q TEXTREL; then exit 1; fi if readelf -d libebl_i386.so | fgrep -q TEXTREL; then exit 1; fi if readelf -d libebl_x86_64.so | fgrep -q TEXTREL; then exit 1; fi rm libebl_sh.map libebl_x86_64.map libebl_ppc64.map libebl_alpha.map libebl_i386.map libebl_ia64.map make[1]: Leaving directory `/usr/local/build/systemtap-obj/build-elfutils/backends' make: *** [stamp-elfutils] Error 2
Since all of the above is really ugly anyway, and it is only used in fairly esoteric circumstances, I just worked around it by adding -j1 to that install step and all is fine.
Cheers,
Mark
It might be broken before. And I wouldn't worry too much about it. The systemtap build only supports is for older distros that need some of the elfutils libs includes in the systemtap install itself. Basically when you use --with-elfutils=/path/to/elfutils/src the configure will do:
I know, I think I wrote that. :-)
) if test $? != 0; then exit; fi
Except I certainly would have written ") || exit" instead. ;-)
Note how we are using bin_PROGRAMS= and only doing an install in the separate build directories.
That is still a "normal enough" way to invoke the makefiles.
This last step goes wrong when we are running parallel make with -j BIG. Then sometimes you will get:
[...]
/usr/bin/ld: cannot open linker script file libebl_ppc.map: No such file or directory collect2: ld returned 1 exit status make[1]: *** [libebl_ppc.so] Error 1 make[1]: *** Waiting for unfinished jobs....
Once in a while I see that in a normal development make run too. AFAICT it's a make bug (which is not my department, no matter what you think you've heard!). The .map file is a dependency of the .so file, so the link should never have been run before that file was created. I don't think anything changed recently that should affect this directly. Perhaps something has slightly changed the timing of some of our build steps so that this happens to hit you more often in the systemtap build than before.
Thanks, Roland
elfutils-devel@lists.fedorahosted.org
-
Mark Wielaard -
Roland McGrath