Hello, yes, indeed the 5.0.7 source deb rebuild is very strange. I also checked the libraries under debian/usr/lib/... in the build directory and they do not contain a libtirpc reference. I can see two possible strategies: 1. Concentrate on the 5.1.1 deb source I grabbed from ubuntu 16.04 and the deb package rebuild from that. Those libraries obviously contain a reference to libtirpc but do not mount anything. Too old libtirpc comes to mind then ? 2. Another approach would be to wait for 16.04 release. I will start deploying 16.04.1 once it is release in the second half of this year. I would then try to rebuild from the deb source including libtirpc (which would be 0.2.5) again and report back. So, basically defering this. If you do not have another idea to get the 5.1.1 deb package rebuild to work I would think that defering and trying with matched and current versions is the right thing to do. Finally to clarify: the comments on manually applying patches and --prefix= refer to building from the pristine source available at https://www.kernel.org/pub/linux/daemons/autofs/v5/, no deb source or package involved. I was working outside the package system. But obviously I do not know enough about building from the pristine source. Thank your very much ! Best Regards Christof On Sat, Apr 09, 2016 at 09:42:06AM +0800, Ian Kent wrote: > On Fri, 2016-04-08 at 16:29 +0200, Christof Koehler wrote: > > Hello, > > > > apparently I confused my 5.1.1 source built experiment and my debian > > package rebuild experiment when I reported that libtirpc was used in > > my > > last email. So here is a new try to rebuild the deb source with > > --with-libtirpc. > > > > I did a apt-get source autofs and added --with-libtirpc to debian > > rules. > > After that it would of course not allow me to build a package, > > "aborting > > due to unexpected upstream changes". So I just did a "dpkg > > -buildpackage > > -b" and then dpkg -i autofs... . Attached is the file build.out.gz > > which > > contains the stdout output. Clearly libtirpc is used somehow in the > > build. > > > > After restoring maps in /etc I did a service restart autofs and with > > debug loglevel I get > > > > Apr 8 16:20:33 core324 automount[14615]: open_mount:247: parse(sun): > > cannot open mount module nfs > > (/usr/lib/x86_64-linux-gnu/autofs/mount_nfs.so: undefined symbol: > > clnt_dg_create) > > > > as reported. I then double checked and actually > > > > root@core324:~# ldd /usr/lib/x86_64-linux-gnu/autofs/mount_nfs.so > > linux-vdso.so.1 => (0x00007ffff7ffd000) > > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 > > (0x00007ffff79f3000) > > /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) > > > > no libtirpc. > > And yet the build from the log looks ok.... > There's no even a link entry there which implies it hasn't been built > using libtirpc but the build looks like it is using it... puzzling. > > Ian > -- > To unsubscribe from this list: send the line "unsubscribe autofs" in -- Dr. rer. nat. Christof Köhler email: c.koehler@xxxxxxxxxxxxxxxxxxx Universitaet Bremen/ BCCMS phone: +49-(0)421-218-62334 Am Fallturm 1/ TAB/ Raum 3.12 fax: +49-(0)421-218-62770 28359 Bremen PGP: http://www.bccms.uni-bremen.de/cms/people/c_koehler/ -- To unsubscribe from this list: send the line "unsubscribe autofs" in
