After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 447577 - VPN service names not multilib friendly
VPN service names not multilib friendly
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Blocks:
 
 
Reported: 2007-06-14 15:47 UTC by Christopher Aillon
Modified: 2007-12-26 13:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
nm-vpndaemons-variable-expansions.patch (1.56 KB, patch)
2007-08-09 18:37 UTC, Robert Buchholz
none Details | Review
networkmanager-pptp-0.6.5_p20070820-service-name.patch (921 bytes, patch)
2007-08-29 19:06 UTC, Robert Buchholz
none Details | Review

Description Christopher Aillon 2007-06-14 15:47:11 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.
Comment 1 Christopher Aillon 2007-06-14 16:47:39 UTC
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 ().
Comment 2 Denis Leroy 2007-06-17 10:21:17 UTC
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.
Comment 3 Christopher Aillon 2007-06-18 17:15:05 UTC
Hm.  Seems very obvious.  Does this work for both 32 and 64 bit?  Seems like it ought to.
Comment 4 Christopher Aillon 2007-06-22 00:02:13 UTC
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
Comment 5 Robert Buchholz 2007-08-09 18:37:25 UTC
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.
Comment 6 Robert Buchholz 2007-08-29 19:06:39 UTC
Created attachment 94570 [details] [review]
networkmanager-pptp-0.6.5_p20070820-service-name.patch

Fixes this for trunk/vpn-daemons/pptp
Comment 7 Dan Williams 2007-08-30 13:59:52 UTC
caillon, you did this, can you commit?
Comment 8 Christopher Aillon 2007-12-26 13:36:57 UTC
pretty sure this is fixed now in both SVN HEAD and the 0.6.5 branch... closing