Exciting :-( adventures in metadata checksumming

On Fri, Aug 03, 2012 at 09:42:39PM -0400, George Spelvin wrote:
> ../lib/libcom_err.so: undefined reference to `sem_post'

Hmm... I have no idea why this is working for me, but I do see the
problem.  I suspect we must be using different versions of Libc, or
the linker, and my environment is much more forgiving, but the problem
is that we're linking -lpthread in the wrong order when creating
libcom_err.so; some how it's not breaking when I do my compiles
though.

The following patch should fix things.  I got a bug report which
pointed out the problem just recently.

					- Ted

commit 037b728b8a6a775e9a5e03fd24b1008d633c1cb4
Author: Theodore Ts'o <tytso@mit.edu>
Date:   Sat Aug 4 16:56:55 2012 -0400

    Put ELF_OTHER_LIBS in the right place for the linker
    
    Commit a7c17431b9 attempted to fix a problem where the system
    libraries might get used instead of local libraries for things like
    -lcom_err.  It tried to accomplish this by moving $(ELF_OTHER_LIBS) to
    before $(LDFLAGS).
    
    Unfortunately, this was the wrong fix; $(ELF_OTHER_LIBS) *MUST* be
    after the object files, or the linker might not pull in the necessary
    library and not include it into the DT_NEEDED section of the shared
    library.  The proper fix is to add a -L$(LIB) before $(LDFLAGS), and
    then remove the -L option from all of the ELF_OTHER_LIBS definitions
    in the library Makefiles.
    
    Addresses-Sourceforge-Bug: #3554345
    
    Cc: Olivier Blin <olivier.blin@softathome.com>
    Reported-by:  Mike Frysinger <vapier@gentoo.org>
    Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>

--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

> commit 037b728b8a6a775e9a5e03fd24b1008d633c1cb4
> Author: Theodore Ts'o <tytso@mit.edu>
> Date:   Sat Aug 4 16:56:55 2012 -0400
>
>     Put ELF_OTHER_LIBS in the right place for the linker

Thanks for the update.  That produces (following your procedure from
the previous e-mail exactly, modulo directory names) a *different* error...

[...snippage...]
gcc -I. -I../../lib -I/tmp/e2fsprogs-1.43/lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -D__NO_STRING_INLINES -c /tmp/e2fsprogs-1.43/lib/ss/get_readline.c
gcc -I. -I../../lib -I/tmp/e2fsprogs-1.43/lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -D__NO_STRING_INLINES -DSHARED_ELF_LIB -fPIC -o elfshared/get_readline.o -c /tmp/e2fsprogs-1.43/lib/ss/get_readline.c
(if test -r libss.a; then /bin/rm -f libss.a.bak && /bin/mv libss.a libss.a.bak; fi)
ar rc libss.a ss_err.o std_rqs.o invocation.o help.o execute_cmd.o listen.o parse.o error.o prompt.o request_tbl.o list_rqs.o pager.o requests.o data.o get_readline.o
/bin/rm -f ../libss.a
(cd ..; /bin/ln  \
                `echo lib/ss | sed -e 's;lib/;;'`/libss.a libss.a)
(cd elfshared; gcc --shared -o libss.so.2.0 -L../../lib -Wl,-Bsymbolic-functions -Wl,-z,relro \
                -Wl,-soname,libss.so.2 ss_err.o std_rqs.o invocation.o help.o execute_cmd.o listen.o parse.o error.o prompt.o request_tbl.o list_rqs.o pager.o requests.o data.o get_readline.o -lcom_err -ldl)
/usr/bin/ld: cannot find -lcom_err
collect2: error: ld returned 1 exit status
make[3]: *** [libss.so.2.0] Error 1
make[3]: Leaving directory `/tmp/e2fsprogs-1.43/debian/BUILD-STD/lib/ss'
make[2]: *** [all-libs-recursive] Error 1
make[2]: Leaving directory `/tmp/e2fsprogs-1.43/debian/BUILD-STD'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/tmp/e2fsprogs-1.43/debian/BUILD-STD'
make: *** [debian/stampdir/build-std-stamp] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


libcom_err certainly exists if you look in the right places:

/tmp/e2fsprogs-1.43$ find debian -name \*com_err\* 
debian/BUILD-STD/lib/libcom_err.so.2.1
debian/BUILD-STD/lib/libcom_err.so.2
debian/BUILD-STD/lib/libcom_err.a
debian/BUILD-STD/lib/et/libcom_err.so.2.1
debian/BUILD-STD/lib/et/elfshared/com_err.o
debian/BUILD-STD/lib/et/com_err.pc
debian/BUILD-STD/lib/et/com_err.o
debian/BUILD-STD/lib/et/libcom_err.a
debian/BUILD-STD/lib/libcom_err.so

The ld was running in debian/BUILD-STD/lib/ss/elfshared, so -L../../lib
is debian/BUILD-STD/lib/lib, which does exist.  Is that right?
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html