Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

make rpm is using host libraries #909

Closed
dechamps opened this issue Aug 29, 2012 · 7 comments
Closed

make rpm is using host libraries #909

dechamps opened this issue Aug 29, 2012 · 7 comments
Labels
Type: Building Indicates an issue related to building binaries
Milestone

Comments

@dechamps
Copy link
Contributor

Note: previous title was "make rpm: undefined reference to zfs_prop_written".

With latest git master, on Debian squeeze, make rpm fails:

$ ./autogen.sh && ./configure --enable-debug --with-config=user && make rpm
[...]
/bin/bash ../../libtool  --tag=CC --silent  --mode=link gcc -Wall -Wstrict-prototypes -fno-strict-aliasing  -DNDEBUG -D_GNU_SOURCE -D__EXTENSIONS__ -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DTEXT_DOMAIN=\"zfs-linux-user\" -O2 -g -pthread -lm -lz -lrt -ldl -luuid  -lselinux  -o mount.zfs mount_zfs.o ../../lib/libuutil/libuutil.la ../../lib/libzfs/libzfs.la -luuid -luuid -lz -lz -lz 
../../lib/libzfs/.libs/libzfs.so: undefined reference to `zfs_prop_written'
collect2: ld returned 1 exit status
make[5]: *** [mount.zfs] Error 1
make[5]: Leaving directory `/tmp/zfs-build-root-CeEUXRma/BUILD/zfs-0.6.0/cmd/mount_zfs'
make[4]: *** [all-recursive] Error 1
make[4]: Leaving directory `/tmp/zfs-build-root-CeEUXRma/BUILD/zfs-0.6.0/cmd'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/tmp/zfs-build-root-CeEUXRma/BUILD/zfs-0.6.0'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/tmp/zfs-build-root-CeEUXRma/BUILD/zfs-0.6.0'
error: Bad exit status from /tmp/zfs-build-root-CeEUXRma/TMP/rpm-tmp.yPK0gX (%build)

Note that, surprisingly, normal make (without rpm) works.

A bissection indicates the issue is caused by ca8b5af.

@dechamps
Copy link
Contributor Author

Okay, I think I understand what's going on. I noticed that if I build debs from the commit before ca8b5af and install them, then the issue disappears. So I wondered if the issue was dependent on what was installed on the system. I came back to the commit before zfs_prop_written was introduced (i.e. 330d06f), build debs, installed them, and tried again with ca8b5af. Sure enough, the issue surfaced again.

So it seems that, starting from ca8b5af, make rpm uses at least some files from the host instead of the files in the distribution being built, which is obviously wrong.

By the way, here's the full build output: https://gist.github.com/3512064

@dechamps
Copy link
Contributor Author

Workaround: uninstall old zfs packages from the system before building the new ones.

@behlendorf
Copy link
Contributor

I always test debian squeeze and haven't seen this issue. Based on your analysis it looks like that's because I always do it with a clean spl/zfs install.

The error and workaround suggest that it's somehow accidentally picking up and older version of libzfs.so. Do you have any idea where it might be finding it?

@dechamps
Copy link
Contributor Author

Well...

# git reset --hard && git clean -xdf && git checkout 330d06f90d143b41b276796526a66a1c1fff046d^
# ./configure && make deb && for DEB in *.deb; do dpkg -i "$DEB"; done
[...]
# git reset --hard && git clean -xdf && git checkout ca8b5af89d2c5826af7385bf18f3b377b0efde11
# ./autogen.sh && ./configure && make rpm
[...]
/bin/bash ../../libtool  --tag=CC --silent  --mode=link gcc -Wall -Wstrict-prototypes -fno-strict-aliasing  -DNDEBUG -D_GNU_SOURCE -D__EXTENSIONS__ -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DTEXT_DOMAIN=\"zfs-linux-user\" -O2 -g -pthread -lm -lz -lrt -ldl -luuid  -lselinux  -o mount.zfs mount_zfs.o ../../lib/libuutil/libuutil.la ../../lib/libzfs/libzfs.la -luuid -luuid -lz -lz -lz 
../../lib/libzfs/.libs/libzfs.so: undefined reference to `zfs_prop_written'
[...]
# dpkg -L zfs | grep /lib64/
/lib64/libnvpair.a
/lib64/libzpool.la
/lib64/libzpool.so.1.0.1
/lib64/libzfs.la
/lib64/libnvpair.so.1.0.1
/lib64/libzfs.a
/lib64/libuutil.so.1.0.1
/lib64/libuutil.la
/lib64/libzfs.so.1.0.1
/lib64/libzpool.a
/lib64/libnvpair.la
/lib64/libuutil.a
/lib64/libnvpair.so.1
/lib64/libzpool.so
/lib64/libuutil.so.1
/lib64/libuutil.so
/lib64/libzfs.so.1
/lib64/libzfs.so
/lib64/libzpool.so.1
/lib64/libnvpair.so
# dpkg -L zfs | grep /lib64/ | xargs rm
# make rpm
(ok)

So, starting from ca8b5af, make rpm is definitely using ZFS libraries from /lib64. It shouldn't.

@dechamps
Copy link
Contributor Author

/tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/cmd/mount_zfs# for FILE in ../../lib/*/.libs/*.so; do echo "$FILE"; nm "$FILE" | grep prop_written; done
../../lib/libnvpair/.libs/libnvpair.so
../../lib/libuutil/.libs/libuutil.so
../../lib/libzfs/.libs/libzfs.so
                 U zfs_prop_written
../../lib/libzpool/.libs/libzpool.so
0000000000029200 T zfs_prop_written

/tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/cmd/mount_zfs# strace -f -e trace=open /bin/bash ../../libtool  --tag=CC --silent  --mode=link gcc -Wall -Wstrict-prototypes -fno-strict-aliasing  -DNDEBUG -D_GNU_SOURCE -D__EXTENSIONS__ -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DTEXT_DOMAIN=\"zfs-linux-user\" -O2 -g -pthread -lm -lz -lrt -ldl -luuid  -lselinux  -o mount.zfs mount_zfs.o ../../lib/libuutil/libuutil.la ../../lib/libzfs/libzfs.la -luuid -luuid -lz -lz -lz 2>&1 | grep libzpool
[pid 11699] open("//lib64/libzpool.so.1", O_RDONLY) = 15
[pid 11699] open("//lib64/libzpool.so.1", O_RDONLY) = 10

/tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/cmd/mount_zfs# cat ../../lib/libzfs/libzfs.la | grep zpool
dependency_libs=' -lm -ldl -lselinux /tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/lib/libnvpair/libnvpair.la /tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/lib/libzpool/libzpool.la /tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/lib/libuutil/libuutil.la -lrt -luuid -lz'
relink_command="(cd /tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/lib/libzfs; /bin/bash /tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/libtool  --tag CC --silent --mode=relink gcc -Wall -Wstrict-prototypes -fno-strict-aliasing -DNDEBUG -D_GNU_SOURCE -D__EXTENSIONS__ -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DTEXT_DOMAIN=\\\"zfs-linux-user\\\" -O2 -g -lm -ldl -version-info 1:1:0 -lselinux -o libzfs.la -rpath //lib64 libzfs_changelist.lo libzfs_config.lo libzfs_dataset.lo libzfs_diff.lo libzfs_fru.lo libzfs_graph.lo libzfs_import.lo libzfs_iter.lo libzfs_mount.lo libzfs_pool.lo libzfs_sendrecv.lo libzfs_status.lo libzfs_util.lo ../../lib/libshare/libshare.la ../../lib/libnvpair/libnvpair.la ../../lib/libzpool/libzpool.la -luuid -luuid -lz -lz -lz @inst_prefix_dir@)"

/tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/cmd/mount_zfs# ldd ../../lib/libzfs/.libs/libzfs.so
    linux-vdso.so.1 =>  (0x00007fffa6bff000)
    libm.so.6 => //lib64/libm.so.6 (0x00007f12b0763000)
    libdl.so.2 => //lib64/libdl.so.2 (0x00007f12b055e000)
    libselinux.so.1 => //lib64/libselinux.so.1 (0x00007f12b0340000)
    libnvpair.so.1 => /tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/lib/libnvpair/.libs/libnvpair.so.1 (0x00007f12b0132000)
    libzpool.so.1 => /tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/lib/libzpool/.libs/libzpool.so.1 (0x00007f12afe13000)
    libuuid.so.1 => //lib64/libuuid.so.1 (0x00007f12afc0f000)
    libz.so.1 => /usr/lib/libz.so.1 (0x00007f12af9f3000)
    libpthread.so.0 => //lib64/libpthread.so.0 (0x00007f12af7d6000)
    libc.so.6 => //lib64/libc.so.6 (0x00007f12af474000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f12b0c2e000)
    libuutil.so.1 => /tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/lib/libuutil/.libs/libuutil.so.1 (0x00007f12af260000)
    librt.so.1 => //lib64/librt.so.1 (0x00007f12af058000)

/tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/cmd/mount_zfs# /bin/bash -x ../../libtool  --tag=CC --silent  --mode=link gcc -Wall -Wstrict-prototypes -fno-strict-aliasing  -DNDEBUG -D_GNU_SOURCE -D__EXTENSIONS__ -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -DTEXT_DOMAIN=\"zfs-linux-user\" -O2 -g -pthread -lm -lz -lrt -ldl -luuid  -lselinux  -o mount.zfs mount_zfs.o ../../lib/libuutil/libuutil.la ../../lib/libzfs/libzfs.la -luuid -luuid -lz -lz -lz
[...]
++ gcc -Wall -Wstrict-prototypes -fno-strict-aliasing -DNDEBUG -D_GNU_SOURCE -D__EXTENSIONS__ -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE '-DTEXT_DOMAIN="zfs-linux-user"' -O2 -g -pthread -o .libs/mount.zfs mount_zfs.o -lm -lrt -ldl -lselinux ../../lib/libuutil/.libs/libuutil.so ../../lib/libzfs/.libs/libzfs.so -luuid -lz -pthread -Wl,-rpath -Wl,//lib64
../../lib/libzfs/.libs/libzfs.so: undefined reference to `zfs_prop_written'

/tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/cmd/mount_zfs# gcc -Wall -Wstrict-prototypes -fno-strict-aliasing -DNDEBUG -D_GNU_SOURCE -D__EXTENSIONS__ -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE '-DTEXT_DOMAIN="zfs-linux-user"' -O2 -g -pthread -o .libs/mount.zfs mount_zfs.o -lm -lrt -ldl -lselinux ../../lib/libuutil/.libs/libuutil.so ../../lib/libzfs/.libs/libzfs.so -luuid -lz -pthread -Wl,-rpath -Wl,//lib64
../../lib/libzfs/.libs/libzfs.so: undefined reference to `zfs_prop_written'
collect2: ld returned 1 exit status

/tmp/zfs-build-root-tnRbUg5a/BUILD/zfs-0.6.0/cmd/mount_zfs# gcc -Wall -Wstrict-prototypes -fno-strict-aliasing -DNDEBUG -D_GNU_SOURCE -D__EXTENSIONS__ -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE '-DTEXT_DOMAIN="zfs-linux-user"' -O2 -g -pthread -o .libs/mount.zfs mount_zfs.o -lm -lrt -ldl -lselinux ../../lib/libuutil/.libs/libuutil.so ../../lib/libzfs/.libs/libzfs.so -luuid -lz -pthread && echo ok
ok

dechamps added a commit to dechamps/zfs that referenced this issue Aug 30, 2012
mount_zfs depends on libzpool for zfs_prop_written since
330d06f. Unfortunately, the Makefile
for mount_zfs has not been modified to reflect this. As a result,
libtool doesn't know about the dependency, which may result in the wrong
libzpool being used during the build (e.g. the libzpool from the system
instead of the libzpool from the build directory).

This patch adds the dependency to fix the issue.

Fixes openzfs#909.
@dechamps
Copy link
Contributor Author

Fixed in #913.

@behlendorf
Copy link
Contributor

Thank you.

pcd1193182 added a commit to pcd1193182/zfs that referenced this issue Sep 26, 2023
Signed-off-by: Paul Dagnelie <[email protected]>
Co-authored-by: Don Brady <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Building Indicates an issue related to building binaries
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants