From: Max T. W. <max...@ve...> - 2005-05-24 17:14:15
|
Earnie Boyd wrote: > > Now you've taken me back to the days of entering binary instructions via > dip switches manually into the computer registers to work around the issue > of the moment. ;p Ahh, just out of curiosity, which machine? Re: Previous discussion in this sub-thread... There are times when getting something working has to be your immediate goal, but you also have to make sure you identify how to implement a long term solution and then actually perform that implementation. That is one of the reasons I'm generating this inane prattle about rebuilding everything from sources. It exposes problems so that they can be fixed properly. I understand the balance between the two processes. That is why I'm going to continue on and ignore the problems with the 'bash' test failures for the moment. I spent several hours last night digging through the 'bash' code trying to locate the source of the problem. My opinion at the moment is that the error message is misleading. It is not that it can not find '/yyy/bash?/bash.exe', it's that it does not think it can execute it. The people who maintain 'bash' need to be told that. There is also the question of why it is being told that 'bash.exe' is not executable. I've not looked into the 'file_status' (or whatever it's called) function that is returning the wrong information. I'd spent too much time on the problem and I was loosing focus on the over-all goal of my project. However I WILL GET BACK TO IT if someone else hasn't found a solution in the mean time. So, Julien's hacking the 'config.h' file is an acceptable short term solution IF IT WORKS (and it will not in this case because it will make the build process and later tests crash), but it is NOT a 'good enough' solution. An example from my own activities is probably in order... I've had trouble with programs including both 'sys/time.h' and 'sys/times.h'. The correct solution is a change to the selector logic so that one or the other is used, but not both. That logic was fairly obviously in a template somewhere because I've seen the exact same code in several places. I'm still not certain how it gets from the template into the project code and until I do, I can't provide anything but an instance by instance solution. That's a job that will take many days. However, there is a short term solution -- hide 'sys/times.h'. I can expose it temporarily if a particular package absolutely requires it. I know this is NOT a 'good enough' solution, but it gets the part of the job I'm working on now done, and I've made note of it so I will get back to it. (I really should have noted this in my postings before this. Me bad... But I try to keep my drivel from driving everyone else up the wall with its banality.) It hurts my pride that I can't solve this and other problems RIGHT NOW, but I can come back to it when I've gotten the bigger job done IF I take proper notes. Hence the chronicle... Which puts another progress report on the agenda -- 'bzip2' is a mess. It does NOT use autoconf. It ONLY wants 'sys/times.h'. I don't see any way to build it except in the same directory as the sources. It does have an 'install' target and you can specify a destination using PREFIX. I got it to build and I was able to stash the results. This is the package I meant when I expressed doubts about 'autoconf' being universally used. 'diffutils' seems to be properly set up. I've configured it, but not built it yet. ma...@mt... |