Matt T. wrote:
Joe, you say you patch the source, I assume you mean the c++ source, may I ask you for an example where you did patch?
See above.
Joe, according to this example you are patching the configure script, and not the c++ source code.
As the configure script (in this case) came with the source, I was patching the program source (i.e. it wasn't getting built automatically during the build process), though you are correct it was not c++ code (above my ability, I am not a programmer). BTW, since I know dansguardian is a c++ program, here is a part of the patch I needed to fix a hardcoded path. --- autoconf/linux.in.orig 2004-09-02 23:31:27.470442186 -0500 +++ autoconf/linux.in 2004-09-02 23:32:57.838906818 -0500 @@ -14,7 +14,7 @@ HTMLTemplate.o LanguageContainer.o DynamicURLList.o ImageContainer.o \ FOptionContainer.o ListManager.o md5.o -LIBS = /usr/lib/libz.a +LIBS = /usr/lib64/libz.a PROG = dansguardian INSTALLFILES = dansguardian dansguardian.conf dansguardian.sysv \ bannedphraselist exceptionsitelist dansguardian.pl \ I don't know what tool was used to produce these files, but this is not old code, but these files were a part of the source tarball.
When I program with kdevelop, I do write c++ code, but I do not write the configure script. The configure script is created for me by kdevelop, which uses autoconf & friends to do the work here.
Which may work fine. Lots of programs will build without patching. Perhaps my conjecture that if most build with no patches, and some build after some hardcoded paths get changed in the program source (via a patch via a spec file) albeit not the c++ code, that the tools would not be at fault, may be a wrong assumption. I truly do not know enough to judge the tools more objectively. It could be old programs built with an outdated autoconf, libtool, etc., I don't know. I just wanted to make sure that the effort to fix any problems were attacking the correct source of the problem, otherwise it would just waste effort and time.
Usually when we download an app as .gz or .bz etc., the configure script is included. So yes, it looks as if it is the app and the programmer of the app, but no, I think in most cases the configure script included with the app had been created more or less automatically, using the tool.
Which makes me wonder, is the tools included with our SuSE that may be at fault, or the tools on the program developer's system? I am not judging your code BTW, just speaking from my limited experience.
That is why I think that these tools need to get fixed, so they produce a configure script which works on 32 bit and on 64 bit systems.
agreed, but it might not be the tools we possess. I know SuSE tests and patches a lot of programs and it might be possible that their particular versions do work. I realize I could be all wrong, though, so take my ramblings as just that. -- Joe Morris New Tribes Mission Email Address: Joe_Morris@ntm.org Registered Linux user 231871