GNOME Bugzilla – Bug 447577
VPN service names not multilib friendly
Last modified: 2007-12-26 13:36:57 UTC
Breaking out from upstream bug https://bugzilla.redhat.com/243535 The problem is that the service.name file contains a hardcoded path to /usr/lib. But this naturally doesn't work on 64bit where it needs to be /usr/lib64. Making this dynamic would add a multilib conflict, though.
We need to remove the path info from the service file and pull this in dynamically. This needs to happen in http://svn.gnome.org/viewcvs/NetworkManager/trunk/gnome/vpn-properties/nm-vpn-properties.c in load_properties_module () and additional changes near the call point in init_app ().
Actually i don't think any code change needs to happen there: you can simply remove the path information from the service file, i.e. change properties=/usr/lib/libnm-vpnc-properties to properties=libnm-vpnc-properties and we're done :-) The string is passed to g_module_open(), then unchanged to dlopen() which recognizes the path as relative and does its thing.
Hm. Seems very obvious. Does this work for both 32 and 64 bit? Seems like it ought to.
Actually, the better solution is to use /usr/${LIB}/libnm-vpnc-properties. dlopen does the right thing here, and the absolute path means that we don't go spending time looking around on disk for the library in all the various ld library paths (a negligible savings really, but...). I just commited this to svn trunk and 0.6.x branch
Created attachment 93385 [details] [review] nm-vpndaemons-variable-expansions.patch Please REOPEN: The patch broke both trunk and 0.6 branch's config files for me because it changes the case of the variables to be expanded. @prefix@ does not get expanded for ppp in trunk, and libexecdir is prepended with ${exec_prefix}. I'll attach a patch for the 0.6 branch, but didn't have a look at trunk.
Created attachment 94570 [details] [review] networkmanager-pptp-0.6.5_p20070820-service-name.patch Fixes this for trunk/vpn-daemons/pptp
caillon, you did this, can you commit?
pretty sure this is fixed now in both SVN HEAD and the 0.6.5 branch... closing