Opened 13 years ago
Closed 12 years ago
#94 closed defect (worksforme)
FindBin failes to find lib64 modules on x86_64 systems
Reported by: | human | Owned by: | |
---|---|---|---|
Version: | 2.x | Keywords: | lib64 FindBin |
Cc: | nkadel@… |
Description
A number of the scripts have a hard-coded 'lib' in the FindBin? statement, which fails on systems with lib64 installation set in the "configure" statements. This causes problems especially with RPM package installations, such as the new one at RPMforge.
I have a patch file for this, based on the older patches from the RPMforge 2.12.1 package.
Attachments (1)
Change History (7)
Changed 13 years ago by human
comment:1 Changed 13 years ago by oetiker
hmmm and who takes care of replacing @@lib@@ with lib64 ? these are no .in files ... ?
comment:2 Changed 13 years ago by human
I see your point. The RedHat? RPM's apply the patch, and then replace the @@lib@@ with '%libdir' as part of the '%install' process, after running 'make install' to the temporarary RPM direcotory in /var/tmp/.
In order to support 64-bit operation, would you consider accepting a patch to Makefile.in and moving the mrtg, cfgmaker, etc. scripts to mrtg.in, cfgmaker.in, etc.? Or would you more easily accept a Makefile.in change that modified the scripts as part of the installation process?
comment:3 Changed 13 years ago by oetiker
hmmm ok, I guess this would be ok. BUT why not make the library path completely arbitrary ? aka configurable ... add it BEFORE what is there now, in that way the *.in version would work too while developing the stuff ...
comment:4 Changed 13 years ago by human
I agree with configurability. I'd do something like you do with the "GRAPHFMT=" settings and the "#*/*perl" lines, but instead of editing the files in place, I'd edit them from an "mrtg.in" script to an "mrtg" script.
In fact, it would make sense to move those setting modifications as well to the "make" process.
comment:5 Changed 13 years ago by oetiker
my only concern is, that I really want to have be able to run mrtg while developing ...
so from a convenience point of view the *.in route is not all that appealing ... inplace editing is much more so ...
comment:6 Changed 12 years ago by oetiker
- Resolution set to worksforme
- Status changed from new to closed
I can not find this problem on my systems, so please submit a proper patch if you like to see this integrated ... I am closing the bug for now.
Uses @@lib@@ instead of lib in FindBin? for lib64 systems.