FindBin failes to find lib64 modules on x86_64 systems

[human]

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.

[human]

Uses @@lib@@ instead of lib in FindBin? for lib64 systems.

[oetiker]

hmmm and who takes care of replacing @@lib@@ with lib64 ? these are no .in files ... ?

[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?

[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 ...

[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.

[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 ...

[oetiker]

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.