Hi All,
I grabbed the elfutils-0.165.tar.bz2 CU82$ tar xf elfutils-0.165.tar.bz2 CU82$ cd elfutils-0.165 CU82$ configure ... ===================================================================== elfutils: 0.165 (eu_version: 165) =====================================================================
Prefix : /usr/local Program prefix ("eu-" recommended) : NONE Source code location : . Maintainer mode : libebl modules subdirectory : elfutils build arch : x86_64-unknown-linux-gnu
RECOMMENDED FEATURES (should all be yes) gzip support : yes bzip2 support : yes lzma/xz support : yes libstdc++ demangle support : yes File textrel check : yes Symbol versioning : yes
NOT RECOMMENDED FEATURES (should all be no) Experimental thread safety : no
OTHER FEATURES Deterministic archives by default : false Native language support : yes
EXTRA TEST FEATURES (used with make check) have bunzip2 installed (required) : yes debug branch prediction : no gprof support : no gcov support : no run all tests under valgrind : no gcc undefined behaviour sanitizer : no use rpath in tests : no test biarch : no
CU82$ make make --no-print-directory all-recursive Making all in config ...
ldgeneric.o: In function `ld_generic_open_outfile': /home/phi/elfutils-0.165/src/ldgeneric.c:2669: warning: the use of `mktemp' is d angerous, better use `mkstemp' or `mkdtemp' CC elflint.o CCLD elflint ./ld: unrecognized option '--sysroot=/' Try `ld --help' or `ld --usage' for more information. collect2: error: ld returned 64 exit status make[2]: *** [elflint] Error 1 rm i386_ld.o make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ========================
Am I doing something obviously wrong ?
Cheers, Phi
On Fri, 2016-02-26 at 19:45 +0100, phi gcc wrote:
I grabbed the elfutils-0.165.tar.bz2 CU82$ tar xf elfutils-0.165.tar.bz2 CU82$ cd elfutils-0.165 CU82$ configure ... ===================================================================== elfutils: 0.165 (eu_version: 165) =====================================================================
Prefix : /usr/local Program prefix ("eu-" recommended) : NONE Source code location : . Maintainer mode : libebl modules subdirectory : elfutils build arch : x86_64-unknown-linux-gnu
RECOMMENDED FEATURES (should all be yes) gzip support : yes bzip2 support : yes lzma/xz support : yes libstdc++ demangle support : yes File textrel check : yes Symbol versioning : yes
NOT RECOMMENDED FEATURES (should all be no) Experimental thread safety : no
OTHER FEATURES Deterministic archives by default : false Native language support : yes
EXTRA TEST FEATURES (used with make check) have bunzip2 installed (required) : yes debug branch prediction : no gprof support : no gcov support : no run all tests under valgrind : no gcc undefined behaviour sanitizer : no use rpath in tests : no test biarch : no
CU82$ make make --no-print-directory all-recursive Making all in config ...
ldgeneric.o: In function `ld_generic_open_outfile': /home/phi/elfutils-0.165/src/ldgeneric.c:2669: warning: the use of `mktemp' is d angerous, better use `mkstemp' or `mkdtemp' CC elflint.o CCLD elflint ./ld: unrecognized option '--sysroot=/' Try `ld --help' or `ld --usage' for more information. collect2: error: ld returned 64 exit status make[2]: *** [elflint] Error 1 rm i386_ld.o make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 ========================
Am I doing something obviously wrong ?
I think what is happening is that you have "." (the current directory) in your PATH. So when the build is in src/ it picks up the just build src/ld program. Which isn't really ready, and doesn't understand --sysroot. Best to remove "." from your PATH.
Cheers,
Mark
Thanx Mark it was this.
Now I am chasing another one, my intent is to build objdump (-g) and I bump into this
CU82$ ldd src/objdump linux-vdso.so.1 => (0x00007ffe859fe000) libasm.so.1 => not found <============= libelf.so.1 => /usr/lib/x86_64-linux-gnu/libelf.so.1 (0x00007ff3a4447000 ) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff3a4243000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff3a3e7e000) /lib64/ld-linux-x86-64.so.2 (0x00007ff3a465d000)
CU82$ ll libasm/libasm.so* -rwxrwxr-x 1 phi phi 171197 Feb 26 20:40 libasm/libasm.so lrwxrwxrwx 1 phi phi 9 Feb 26 20:40 libasm/libasm.so.1 -> libasm.so
Sounds like this is built yet it doen't find/use it.
Cheers, Phi
I didn't made a make install on purpose may I shoul but I don't want to push things built here on my system... Whant to build pure local under the tar xv dir
On Fri, 2016-02-26 at 21:11 +0100, phi gcc wrote:
I didn't made a make install on purpose may I shoul but I don't want to push things built here on my system... Whant to build pure local under the tar xv dir
I would recommend using something like configure --prefix=/usr/local/elfutils --program-prefix=eu- to install under /usr/local/elfutils and have all programs start with eu-... so they don't clash with any existing ones.
If you do want to run the programs in the build directory you'll have to set the LD_LIBRARY_PATH. LD_LIBRARY_PATH=backends:libelf:libdw:libasm src/objdump --help
LD_LIBRARY_PATH saved me, since I dont install no need for prefix and I can run from src (i.e src/objdump)
Now to my grand surprise no dwarf option in this 'latest' objdump,
My intent was to rebuilf objdump -g so I can debug it and see why it barf on my a.out debug infos.
HI Mark and All
I am pretty happy with readelf for what I am doing, yet I got one more question is there a way to build readelf linked -archive with ../libelf ../libdw
I build readelf -g as well as the ../lib* and I need to debug all that.
I am asking for a 'normal' ay of doing this, i.e is there a "make something" that I should do.
Else I will do a final LD manually.
Cheers, Phi
For the time being I am patching the Makefile uncommenting the .a lines let me know if there is a more standard way may be to ./configure saying we want archive building.
Cheers, Phi
On Sun, 2016-02-28 at 08:40 +0100, phi gcc wrote:
HI Mark and All
I am pretty happy with readelf for what I am doing, yet I got one more question is there a way to build readelf linked -archive with ../libelf ../libdw
I build readelf -g as well as the ../lib* and I need to debug all that.
I am asking for a 'normal' ay of doing this, i.e is there a "make something" that I should do.
If you are asking whether elfutils supports static linking then then the answer is currently no. The tools, libdw and libasm that rely on libebl load the backend code for the various arches through ldopen. See eblopenbackend.c.
If you are asking how to debug a non-installed version of an elfutils tool then doing the following should just work: LD_LIBRARY_PATH=backends:libelf:libdw:libasm gdb --args src/readelf ...
Cheers,
Mark
On Fri, 2016-02-26 at 21:11 +0100, phi gcc wrote: > I didn't made a make install on purpose may I shoul but I don't want > to push things built here on my system... > Whant to build pure local under the tar xv dir
I would recommend using something like configure --prefix=/usr/local/elfutils --program-prefix=eu- to install under /usr/local/elfutils and have all programs start with eu-... so they don't clash with any existing ones.
And speaking of that... what about setting the program-prefix to eu- by default?
Almost no one wants the elfutils to replace binutils, but to complement them. But that can happen by accident very easily with the default program names.
Also, we are so used to use eu-stack and the other eu-* commands that using stack, etc feels weird :)
What you people think?
I think we need to understand how people who build the elfutils use them.
1) Distro owner make them then package it then test/deliver it. That the one that comes as binary on my machine and I would use to check the a.out I am producing on my machine.
2) Developper who need to inspect a.out he/she didn't produced. In my case I am loged on a development machine, and I receive a.out I didn't produced locally (linux kernels comming from various distro, with kernel ranging from 2.6.1x to 4.x my dev machine seating somewhere in the middle.
I need to build locally an elfutils, generally the latest one that is able to read the old a.out (old dwarf, i.e dwarf 2) and I can also read very recent a.out i.e dwarf4.
When I buid those very latest elfutils, I dont want to temper with the binary that comes with my distro, and I don't want to type very long name, yet this later I can use aliases so it is not a real argument.
Well I figured that with a descent environment (No '.' in PATH) and I can build elfutils, I figured that by hacking the makefile we can build archived so I can move my build around on other nodes if needed, and that my binaries are located in src/ not really the place I imagined :)
All in all now I am operational with elfutils and it is a very good tools set.
Cheers, Phi
On Fri, Feb 26, 2016 at 11:43 PM, Jose E. Marchesi jose.marchesi@oracle.com wrote:
On Fri, 2016-02-26 at 21:11 +0100, phi gcc wrote: > I didn't made a make install on purpose may I shoul but I don't want > to push things built here on my system... > Whant to build pure local under the tar xv dir I would recommend using something like configure --prefix=/usr/local/elfutils --program-prefix=eu- to install under /usr/local/elfutils and have all programs start with eu-... so they don't clash with any existing ones.
And speaking of that... what about setting the program-prefix to eu- by default?
Almost no one wants the elfutils to replace binutils, but to complement them. But that can happen by accident very easily with the default program names.
Also, we are so used to use eu-stack and the other eu-* commands that using stack, etc feels weird :)
What you people think?
On Fri, 2016-02-26 at 14:43 -0800, Jose E. Marchesi wrote:
I would recommend using something like configure --prefix=/usr/local/elfutils --program-prefix=eu- to install under /usr/local/elfutils and have all programs start with eu-... so they don't clash with any existing ones.
And speaking of that... what about setting the program-prefix to eu- by default?
Almost no one wants the elfutils to replace binutils, but to complement them. But that can happen by accident very easily with the default program names.
Also, we are so used to use eu-stack and the other eu-* commands that using stack, etc feels weird :)
What you people think?
Good idea. How about the following patch?
Cheers,
Mark
> And speaking of that... what about setting the program-prefix to eu- by > default? > > Almost no one wants the elfutils to replace binutils, but to complement > them. But that can happen by accident very easily with the default > program names. > > Also, we are so used to use eu-stack and the other eu-* commands that > using stack, etc feels weird :) > > What you people think?
Good idea. How about the following patch?
Sweet. Install it! :D
On Wed, 2016-03-02 at 08:00 -0800, Jose E. Marchesi wrote:
> And speaking of that... what about setting the program-prefix to eu- by > default? > > Almost no one wants the elfutils to replace binutils, but to complement > them. But that can happen by accident very easily with the default > program names. > > Also, we are so used to use eu-stack and the other eu-* commands that > using stack, etc feels weird :) > > What you people think? Good idea. How about the following patch?
Sweet. Install it! :D
OK, pushed to master. It passed make distcheck, so it must be perfect.
Please do let me know if it causes any issues for anybody.
Thanks,
Mark
elfutils-devel@lists.fedorahosted.org