Bug#493217: libnfsidmap-0.21 is available
On Wed, Aug 27, 2008 at 12:20 PM, Steve Dickson <[EMAIL PROTECTED]> wrote: > Kevin Coffman wrote: >>> --- libnfsidmap-0.21/libnfsidmap.c~ 2008-08-02 10:52:00.289845221 +1200 >>> +++ libnfsidmap-0.21/libnfsidmap.c 2008-08-02 10:47:50.647889312 +1200 >>> @@ -101,7 +101,7 @@ >>>char plgname[128]; >>>int ret = 0; >>> >>> - snprintf(plgname, sizeof(plgname), "%s%s.so", PLUGIN_PREFIX, >>> method); >>> + snprintf(plgname, sizeof(plgname), "%s%s.so.0", PLUGIN_PREFIX, >>> method); >>> >>>dl = dlopen(plgname, RTLD_NOW | RTLD_LOCAL); >>>if (dl == NULL) { >>> >>> >> >> Getting back to this. I'm curious if there is a specific reason why >> the *.so symlink was not there? Adding the ".0" shouldn't be >> necessary. But there may be a reason for not including the .so >> symlink that I am not aware of. > The reason the version (or a version) number is need is because > some distros only installed the .so with the -devel package which > is not normally installed... The question is how do we get the > version to change automagically when the soname changes? > > steved. OK. I will add something. Maybe the patch you sent privately. I'll look into the possibility of tying it with the autoconf stuff when the version changes. Also for the list: I'll move this code to a git repository next week to make things more "open". K.C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
Kevin Coffman wrote: >> --- libnfsidmap-0.21/libnfsidmap.c~ 2008-08-02 10:52:00.289845221 +1200 >> +++ libnfsidmap-0.21/libnfsidmap.c 2008-08-02 10:47:50.647889312 +1200 >> @@ -101,7 +101,7 @@ >>char plgname[128]; >>int ret = 0; >> >> - snprintf(plgname, sizeof(plgname), "%s%s.so", PLUGIN_PREFIX, method); >> + snprintf(plgname, sizeof(plgname), "%s%s.so.0", PLUGIN_PREFIX, >> method); >> >>dl = dlopen(plgname, RTLD_NOW | RTLD_LOCAL); >>if (dl == NULL) { >> >> > > Getting back to this. I'm curious if there is a specific reason why > the *.so symlink was not there? Adding the ".0" shouldn't be > necessary. But there may be a reason for not including the .so > symlink that I am not aware of. The reason the version (or a version) number is need is because some distros only installed the .so with the -devel package which is not normally installed... The question is how do we get the version to change automagically when the soname changes? steved. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
"Kevin Coffman" <[EMAIL PROTECTED]> writes: > Getting back to this. I'm curious if there is a specific reason why > the *.so symlink was not there? Adding the ".0" shouldn't be > necessary. But there may be a reason for not including the .so > symlink that I am not aware of. > > My default install in /usr/local/lib shows: > > lrwxrwxrwx 1 root root29 2008-07-30 16:59 > /usr/local/lib/libnfsidmap_nsswitch.so -> libnfsidmap_nsswitch.so.0.0.0 > lrwxrwxrwx 1 root root29 2008-07-30 16:59 > /usr/local/lib/libnfsidmap_nsswitch.so.0 -> libnfsidmap_nsswitch.so.0.0.0 > -rwxr-xr-x 1 root root 17141 2008-07-30 16:59 > /usr/local/lib/libnfsidmap_nsswitch.so.0.0.0 This looks like a reasonable result from "make install" in a regular autotooled source distribution. The libfoo.so link is used by the linker to find the library based on the -lfoo switch. The object resulting from the link will refer to libfoo.so.X and then that will be a symlink to libfoo.so.X.Y.Z. So far, so good. With typical libraries on Debian, libfoo.so will be provided, along with the required headers, by libfoo-dev (or perhaps libfooX-dev, depending on how it has been packaged). libfoo.so.X and libfoo.so.X.Y.Z will be in the libfooX package (or perhaps libfoo, if X has never changed), and applications linked to libfoo will depend on that package, as will libfoo-dev. Of course, the shared objects we're talking about are not regular libraries and so should be handled specially. This could mean altering the dlopen calls as per my suggestion, or overriding the autotools stuff and installing them as libnfsidmap_foo.so somewhere or other. -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
On Fri, Aug 1, 2008 at 6:57 PM, Paul Collins <[EMAIL PROTECTED]> wrote: > "Kevin Coffman" <[EMAIL PROTECTED]> writes: >> On Fri, Aug 1, 2008 at 9:41 AM, Paul Collins <[EMAIL PROTECTED]> wrote: >>> "Kevin Coffman" <[EMAIL PROTECTED]> writes: >>> Did you run ldconfig? I was trying to find the right thing to force that, but from what I saw, when you install in /usr/local/lib, libtool knows better. If anyone has the answer on that, let me know. >>> >>> The convention on Debian seems to be to install plugins as >>> /usr/lib/${packagename}/${plugin}.so and dlopen them with an absolute path. >> >> OK, I'll update the code and put out a -0.22 ASAP, but it might not be >> for a few days. > > Having had some sleep, I realized a quicker fix is to just change the > dlopen calls to do e.g. dlopen("libfoo.so.0", ...). This would avoid > any tussling with libtool and the autogar, which is always a plus. > > I've tried that out here and it works nicely. Patch below. > >> BTW, this is the kind of comments I was looking for since putting the >> beta out in April, but received none. I guess I was asking in the >> wrong places. :-/ > > You may have to just be bold and trick people into testing your betas by > calling them releases. I'm happy to complain about anything that ends > up in Debian unstable, but I tend not to grab stuff from upstream much. > > > --- libnfsidmap-0.21/libnfsidmap.c~ 2008-08-02 10:52:00.289845221 +1200 > +++ libnfsidmap-0.21/libnfsidmap.c 2008-08-02 10:47:50.647889312 +1200 > @@ -101,7 +101,7 @@ >char plgname[128]; >int ret = 0; > > - snprintf(plgname, sizeof(plgname), "%s%s.so", PLUGIN_PREFIX, method); > + snprintf(plgname, sizeof(plgname), "%s%s.so.0", PLUGIN_PREFIX, > method); > >dl = dlopen(plgname, RTLD_NOW | RTLD_LOCAL); >if (dl == NULL) { > > Getting back to this. I'm curious if there is a specific reason why the *.so symlink was not there? Adding the ".0" shouldn't be necessary. But there may be a reason for not including the .so symlink that I am not aware of. My default install in /usr/local/lib shows: lrwxrwxrwx 1 root root29 2008-07-30 16:59 /usr/local/lib/libnfsidmap_nsswitch.so -> libnfsidmap_nsswitch.so.0.0.0 lrwxrwxrwx 1 root root29 2008-07-30 16:59 /usr/local/lib/libnfsidmap_nsswitch.so.0 -> libnfsidmap_nsswitch.so.0.0.0 -rwxr-xr-x 1 root root 17141 2008-07-30 16:59 /usr/local/lib/libnfsidmap_nsswitch.so.0.0.0 Thanks, K.C. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
"Kevin Coffman" <[EMAIL PROTECTED]> writes: > On Fri, Aug 1, 2008 at 9:41 AM, Paul Collins <[EMAIL PROTECTED]> wrote: >> "Kevin Coffman" <[EMAIL PROTECTED]> writes: >> >>> Did you run ldconfig? I was trying to find the right thing to force >>> that, but from what I saw, when you install in /usr/local/lib, libtool >>> knows better. If anyone has the answer on that, let me know. >> >> The convention on Debian seems to be to install plugins as >> /usr/lib/${packagename}/${plugin}.so and dlopen them with an absolute path. > > OK, I'll update the code and put out a -0.22 ASAP, but it might not be > for a few days. Having had some sleep, I realized a quicker fix is to just change the dlopen calls to do e.g. dlopen("libfoo.so.0", ...). This would avoid any tussling with libtool and the autogar, which is always a plus. I've tried that out here and it works nicely. Patch below. > BTW, this is the kind of comments I was looking for since putting the > beta out in April, but received none. I guess I was asking in the > wrong places. :-/ You may have to just be bold and trick people into testing your betas by calling them releases. I'm happy to complain about anything that ends up in Debian unstable, but I tend not to grab stuff from upstream much. --- libnfsidmap-0.21/libnfsidmap.c~ 2008-08-02 10:52:00.289845221 +1200 +++ libnfsidmap-0.21/libnfsidmap.c 2008-08-02 10:47:50.647889312 +1200 @@ -101,7 +101,7 @@ char plgname[128]; int ret = 0; - snprintf(plgname, sizeof(plgname), "%s%s.so", PLUGIN_PREFIX, method); + snprintf(plgname, sizeof(plgname), "%s%s.so.0", PLUGIN_PREFIX, method); dl = dlopen(plgname, RTLD_NOW | RTLD_LOCAL); if (dl == NULL) { -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
OK, I'll update the code and put out a -0.22 ASAP, but it might not be for a few days. BTW, this is the kind of comments I was looking for since putting the beta out in April, but received none. I guess I was asking in the wrong places. :-/ On Fri, Aug 1, 2008 at 9:41 AM, Paul Collins <[EMAIL PROTECTED]> wrote: > "Kevin Coffman" <[EMAIL PROTECTED]> writes: > >> Did you run ldconfig? I was trying to find the right thing to force >> that, but from what I saw, when you install in /usr/local/lib, libtool >> knows better. If anyone has the answer on that, let me know. > > The convention on Debian seems to be to install plugins as > /usr/lib/${packagename}/${plugin}.so and dlopen them with an absolute path. > > -- > Paul Collins > Wellington, New Zealand > > Dag vijandelijk luchtschip de huismeester is dood > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
"Kevin Coffman" <[EMAIL PROTECTED]> writes: > Did you run ldconfig? I was trying to find the right thing to force > that, but from what I saw, when you install in /usr/local/lib, libtool > knows better. If anyone has the answer on that, let me know. The convention on Debian seems to be to install plugins as /usr/lib/${packagename}/${plugin}.so and dlopen them with an absolute path. -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
Did you run ldconfig? I was trying to find the right thing to force that, but from what I saw, when you install in /usr/local/lib, libtool knows better. If anyone has the answer on that, let me know. On Fri, Aug 1, 2008 at 8:15 AM, Aníbal Monsalve Salazar <[EMAIL PROTECTED]> wrote: > On Wed, Jul 30, 2008 at 06:41:04PM -0400, Kevin Coffman wrote: >>A new version of libnfsidmap is now available from >>http://www.citi.umich.edu/projects/nfsv4/linux/libnfsidmap/libnfsidmap-0.21.tar.gz >> >>Changes since libnfsidmap-0.20: >> >> - The main library has been changed to load "plugin" libraries to >>perform the mappings. This decouples the main library from any ldap >>(and sasl, etc.) dependencies. >> >> - Several translation methods (plugins) may now be specified in the >>idmapd.conf file. While a plugin returns -ENOENT, the next is called >>until a mapping is found, or there are no more plugins to try. See >>the notes in the updated sample idmapd.conf configuration file. >> >> - A "static" mapping plugin from David Härdeman <[EMAIL PROTECTED]> >>has been added. >> >> - A "gums" mapping plugin from Olga Kornievskaia >><[EMAIL PROTECTED]> has been added. Olga also did most of the work >>to convert the code to use this new plugin architecture. >> >> - The interface is changed to add two new functions, >>nfs4_gss_princ_to_ids_ex(), and nfs4_gss_princ_to_grouplist_ex() which >>allow extra information to be passed to these mapping functions. > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493217 > > Upgrading from 0.20-1 to 0.21-1 breaks rpc.idmapd: > > On Fri, Aug 01, 2008 at 11:40:32PM +1200, Paul Collins wrote: >>Package: libnfsidmap2 >>Version: 0.21-1 >>Severity: grave >> >>Upgrading from 0.20-1 to 0.21-1 breaks rpc.idmapd: >> >> $ sudo rpc.idmapd -f -v >> rpc.idmapd: libnfsidmap: using domain: wgtn.ondioline.org >> >> rpc.idmapd: libnfsidmap: processing 'Method' list >> >> rpc.idmapd: libnfsidmap: Unable to load plugin: libnfsidmap_nsswitch.so: >> cannot open shared object file: No such file or directory >> >> rpc.idmapd: libnfsidmap: requested translation method, 'nsswitch', is not >> available >> >> rpc.idmapd: Unable to create name to user id mappings. >> $ dpkg -L libnfsidmap2 | grep nsswitch >> /usr/lib/libnfsidmap_nsswitch.so.0.0.0 >> /usr/lib/libnfsidmap_nsswitch.so.0 >> >>Since these newly separated plugins are not general-purpose shared >>libraries, perhaps they should be shipped as >>/usr/lib/libnfsidmap2/nsswitch.so and so forth, or something along >>those lines. >> >>-- >>Paul Collins >>Wellington, New Zealand > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkiS/lkACgkQgY5NIXPNpFUEIwCeMFaqLcd6mpgQZO0A6SH1bJ8d > zfMAniS2YmUgosrfYbgIs9hCnUq+GZn5 > =s8E4 > -END PGP SIGNATURE- > > ___ > NFSv4 mailing list > [EMAIL PROTECTED] > http://linux-nfs.org/cgi-bin/mailman/listinfo/nfsv4 > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#493217: libnfsidmap-0.21 is available
On Wed, Jul 30, 2008 at 06:41:04PM -0400, Kevin Coffman wrote: >A new version of libnfsidmap is now available from >http://www.citi.umich.edu/projects/nfsv4/linux/libnfsidmap/libnfsidmap-0.21.tar.gz > >Changes since libnfsidmap-0.20: > > - The main library has been changed to load "plugin" libraries to >perform the mappings. This decouples the main library from any ldap >(and sasl, etc.) dependencies. > > - Several translation methods (plugins) may now be specified in the >idmapd.conf file. While a plugin returns -ENOENT, the next is called >until a mapping is found, or there are no more plugins to try. See >the notes in the updated sample idmapd.conf configuration file. > > - A "static" mapping plugin from David Härdeman <[EMAIL PROTECTED]> >has been added. > > - A "gums" mapping plugin from Olga Kornievskaia ><[EMAIL PROTECTED]> has been added. Olga also did most of the work >to convert the code to use this new plugin architecture. > > - The interface is changed to add two new functions, >nfs4_gss_princ_to_ids_ex(), and nfs4_gss_princ_to_grouplist_ex() which >allow extra information to be passed to these mapping functions. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=493217 Upgrading from 0.20-1 to 0.21-1 breaks rpc.idmapd: On Fri, Aug 01, 2008 at 11:40:32PM +1200, Paul Collins wrote: >Package: libnfsidmap2 >Version: 0.21-1 >Severity: grave > >Upgrading from 0.20-1 to 0.21-1 breaks rpc.idmapd: > > $ sudo rpc.idmapd -f -v > rpc.idmapd: libnfsidmap: using domain: wgtn.ondioline.org > > rpc.idmapd: libnfsidmap: processing 'Method' list > > rpc.idmapd: libnfsidmap: Unable to load plugin: libnfsidmap_nsswitch.so: > cannot open shared object file: No such file or directory > > rpc.idmapd: libnfsidmap: requested translation method, 'nsswitch', is not > available > > rpc.idmapd: Unable to create name to user id mappings. > $ dpkg -L libnfsidmap2 | grep nsswitch > /usr/lib/libnfsidmap_nsswitch.so.0.0.0 > /usr/lib/libnfsidmap_nsswitch.so.0 > >Since these newly separated plugins are not general-purpose shared >libraries, perhaps they should be shipped as >/usr/lib/libnfsidmap2/nsswitch.so and so forth, or something along >those lines. > >-- >Paul Collins >Wellington, New Zealand signature.asc Description: Digital signature