howto not strip .so on install

[Jerry James]

On Wed, Jul 27, 2011 at 12:06 PM, Jerry James <loganjerry at 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.
-- 
Jerry James
http://www.jamezone.org/