On Wed, 25 Apr 2012 00:01:47 -0500, David C. Rankin wrote:
On 04/24/2012 04:54 PM, François ANDRIOT wrote:Le 24/04/2012 23:27, Darrell Anderson a écrit :Sorry, I forgot to attach the patch to my previous mail. Here is the patch for tqca-tls, working on fedora 16 x86_64 (tde r14 + tqt3) .I will look into them, but I think these packages are for R14 and I'm focusing on 3.5.13 for now. I've already built tqca-tls R14 with TQT3 bt writing the attached patch (see first part).Where do I look for the patches? I'm okay with your patches being for 3.5.13. I can massage/adapt them to GIT. I have been doing that regularly around here. :)I am the packager for both RHEL and Fedora. RHEL is like an "old stable Fedora", the packaging method and tools are exactly the same, thanks to the Redhat RPM tools That's why If you look in the git tree "tde-packaging", only the "redhat" folder is populated. But I have to compile my sources for each distro (currently I compile each package 10 times: RHEL5, RHEL6, Fedora15, Fedora16, Fedora17, each distro for both x86 and x86_64). As a bonus, I've just done the patch for tqca (tested on fedora 16 x86_64, tde r14, tqt3). It is attached to this mail too. I did not look yet but I guess that the trinity-python package has more or less the same problem. FrancoisProblems occur when the "configure" script is not autogenerated but is a static shell script, it often lacks the "lib64" directories in path ...Yes, that is the case. I need to learn how to fix only one of each (tqca or tqca-tls and python-tqt or python-trinity). After I learn to fix one of each I should be able to do likewise for the other. The challenge with the two python packages is the configuration scripts are written in python, which I don't know. By the way, are your Fedora packages compatible with other Redhat spinoff releases, such as Scientific Linux? Just curious.Francios, Is this configurable for those distros that do NOT utilize lib64 for 64-bit library packages? While openSuSE does put 64-bit libs in lib64, Archlinux puts all libs lin 'libs' on 64-bit boxes. This needs to be configurable for just this case. Otherwise always putting 64-bit libs in lib64 on boxes that do NOT use lib64 will really screw up the library search and build system. Can it be something like a --target option or a --with-64bit-lib-dirs= configure option? We don't want a one-size doesn't fit all solution. That would cause about an equal number of problems as it purportedly resolves for those distros that put 64bit libs in libs.
The patch should work for both "lib64" and "lib" directory, or any other location that your system use for libraries.
Just try it and see if you get the expected result.