Jerry James wrote:
On Wed, Jul 27, 2011 at 12:06 PM, Jerry James
<loganjerry(a)gmail.com> wrote:
> It isn't strip. If I run strip on the version of libmtcp.so left in
> the build dir and copy it over /usr/lib64/dmtcp/libmtcp.so, then it
> also works. But that version is different from the one installed by
> rpm. Watch this:
>
> $ ldd -r /usr/lib64/dmtcp/libmtcp.so
> linux-vdso.so.1 => (0x00007fff7d7c3000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f913f396000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f913f17b000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f913ef65000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f913ebcc000)
> /lib64/ld-linux-x86-64.so.2 (0x0000003520600000)
> undefined symbol: mtcp_restore_start (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: dmtcp_exists (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: mtcp_restore_argv_start_addr (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: mtcp_sys_errno (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: mtcp_get_thread_sysinfo (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: mtcp_no (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: mtcp_dump_tls (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: mtcp_readdec (/usr/lib64/dmtcp/libmtcp.so)
> undefined symbol: test_and_prepare_for_forked_ckpt
> (/usr/lib64/dmtcp/libmtcp.so) undefined symbol: write_ckpt_to_file
> (/usr/lib64/dmtcp/libmtcp.so) undefined symbol: mtcp_readchar
> (/usr/lib64/dmtcp/libmtcp.so) $ ldd -r /tmp/libmtcp-stripped.so
> linux-vdso.so.1 => (0x00007fffcd3ff000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00007f02082b3000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f0208098000)
> libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f0207e82000)
> libc.so.6 => /lib64/libc.so.6 (0x00007f0207ae9000)
> /lib64/ld-linux-x86-64.so.2 (0x0000003520600000)
>
> The program /usr/lib/rpm/debugedit is used to extract debug
> information from ELF objects when building RPMs. It looks like it is
> damaging the shared object somehow.
Hmmmm, the dmtcp project is patching the default linker script:
make[1]: Entering directory
`/home/jamesjer/rpmbuild/BUILD/dmtcp-1.2.3+svn1214/mtcp'
rm -f mtcp.t
ld -shared --verbose > mtcp.t
sed -i -e '1,/========================/ d' mtcp.t
sed -i -e '/========================/,$ d' mtcp.t
rm -f mtcp.t-fail
if test x86_64 = x86_64; then \
if patch mtcp.t mtcp.t.patch-x86_64; then \
:; \
else \
mv mtcp.t mtcp.t-fail; false; \
fi \
else \
if patch mtcp.t mtcp.t.patch-i386; then \
:; \
else \
mv mtcp.t mtcp.t-fail; false; \
fi \
fi
patching file mtcp.t
Hunk #1 succeeded at 6 with fuzz 2.
Hunk #2 succeeded at 189 (offset 14 lines).
...
gcc -shared -fPIC -T mtcp.t -Wl,-Map,mtcp.map -o libmtcp.so \
mtcp.o mtcp_restart_nolibc.o mtcp_maybebpt.o mtcp_printf.o
mtcp_util.o mtcp_safemmap.o mtcp_safe_open.o mtcp_state.o
mtcp_check_vdso.o mtcp_sigaction.o mtcp_ptrace.o mtcp_fastckpt.o -ldl
-lpthread
Here's the diff against the default linker script:
--- linker.default 2011-07-27 12:09:30.492379093 -0600
+++ mtcp.t 2011-07-27 11:48:10.803379078 -0600
@@ -1,12 +1,3 @@
-GNU ld version 2.21.51.0.6-6.fc15 20110118
- Supported emulations:
- elf_x86_64
- elf32_x86_64
- elf_i386
- i386linux
- elf_l1om
-using internal linker script:
-==================================================
/* Script for --shared -z combreloc: shared library, combine & sort relocs */
OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64",
"elf64-x86-64")
@@ -15,6 +6,9 @@
SEARCH_DIR("/usr/x86_64-redhat-linux/lib64");
SEARCH_DIR("/usr/local/lib64"); SEARCH_DIR("/lib64");
SEARCH_DIR("/usr/lib64");
SEARCH_DIR("/usr/x86_64-redhat-linux/lib");
SEARCH_DIR("/usr/lib64"); SEARCH_DIR("/usr/local/lib");
SEARCH_DIR("/lib"); SEARCH_DIR("/usr/lib");
SECTIONS
{
+ .the.begin : {
+ *(__shareable_begin)
+ }
/* Read-only sections, merged into text segment: */
. = SEGMENT_START("text-segment", 0) + SIZEOF_HEADERS;
.note.gnu.build-id : { *(.note.gnu.build-id) }
@@ -195,6 +189,9 @@
*(.ldata .ldata.* .gnu.linkonce.l.*)
. = ALIGN(. != 0 ? 64 / 8 : 1);
}
+ .the.end : {
+ *(__shareable_end)
+ }
. = ALIGN(64 / 8);
_end = .; PROVIDE (end = .);
. = DATA_SEGMENT_END (.);
@@ -239,4 +236,3 @@
}
-==================================================
That may or may not have something to do with your problem, but it
probably bears looking into.
Sounds like the best course of action is to just disable debugedit?
1. Would this be acceptable for a fedora package?
2. Is it possible to disable debugedit?