On Mon, 2003-11-03 at 03:58, Net Virtual Mailing Lists wrote: > #1. qmail-1.03 - won't compile, "undefined reference to errno" http://www.qmailrocks.org/qmail.htm > #2. php-4.3.1 - won't compile when --with-mysql is specified "undefined > reference to errno" (presumably this is fixed in the CVS version of PHP, > but I cannot really consider running a CVS version of anything in a > production environment) > > #3. php-4.3.1 - when --with-mysql=/usr is specified (causing PHP to not > use it's internal mysql code), I get the following errors: > A. warning: implicit declaration of function `getpgid' > B. warning: implicit declaration of function `pread' > C. warning: implicit declaration of function `pwrite' > D. the use of `tmpnam' is dangerous, better use `mkstemp` It seems that plenty of folks have problems compilng PHP 4.3.x against gcc-3.x. I'm not a PHP expert, but I'd try Red Hat's compat-gcc-c++-7.3-2.96.118 compiler, if I were you. If you don't absolutely have to have the bleeding edge, use Red Hat's binary releases of php-4.2.2, php-mysql-4.2.2, etc. > #4. apache-1.3.29 - the use of `tmpnam' is dangerous, better use `mkstemp Same thing, try the other compiler. > #5. htdig-3.1.6 - configure fails 'checking for fstream.h'... (yes the > g++ rpm is installed).. Making me wonder: > A. Are configure scripts for other things failing to detect header > files and 'falling back' to some deprecated APIs? > B. Could that be what the tmpname error is related to? > C. How can I possibly rely upon this development environment? On Red Hat 9, fstream.h is found in /usr/include/g++-3/. You'll probably need to pass it the include directives. See "./configure --help" for more compile options. > ... As I am sure anyone with a large number of servers to manage is > aware, having odd development environments which require 'special > handling' is a nightmare to deal with. It blows my mind that I have > only started to configure this server and so far 5 out 5 software builds > have 'failed' (by my standards) to configure, compile, or install properly. Honestly, it's your (or your client's) own fault for using bleeding-edge software on a distribution with a bleeding-edge development environment. I'd suggest that you use the stock Red Hat packages, where possible. Where it's not, you should do more research via Google. You'll be able to install of of your packages on Red Hat 9, but it's going to require a "little" extra effort. > My specific questions are: > 1. Am I doing something wrong trying to configure/compile this software? Impossible to know without knowing what your client's needs are. If you don't require bleeding-edge releases, fall back to Red Hat's binary packages. > 2. Should I consider the installation of RH 9 to be suspect at this point? No, Google says these are known problems with known work-arounds. > 3. Is there something wrong with the RH 9 development environment? Sounds mainly like you're getting cut on the bleeding-edge that is gcc-3.x. Try the compat compiler. > 4. If I stick with RH Linux, should I downgrade to 7.2? Not unless you like backporting your own patches. December 31st marks the end-of-life for Red Hat 7.2. > 5. What are your thoughts on RH's long-term strategy in this area? Is > RH 10 going to introduce the same magnitude of problems all over again? > Should integrators/administrators anticipate these sort of problems > (which don't seem to exist to this level in other OSes) when upgrading? The blame is not on Red Hat to verify that all 3rd party's software compiles properly on their platform. They release binary packages of the most popular software packages (Apache-1.3.x being the lone exception) that will meet 99% of your needs. If you choose to use non-standard software, the onus of support falls back on you or the software developer, not Red Hat. > Sorry if I seem overly bitter - I've been fighting with this all weekend > and have now missed a very important deadline as a result. These > packages I am trying to compile comprise about 10% of the software I need > to install on our servers and if I can't even get through these I can > only imagine what lies in store for me as I move on to the more complex > ones which are not updated as frequently.... If you'd like to subcontract out your installation work, you know where to find me. ;-) -- Jason Dixon, RHCE DixonGroup Consulting http://www.dixongroup.net -- redhat-list mailing list unsubscribe mailto:redhat-list-request@xxxxxxxxxx?subject=unsubscribe https://www.redhat.com/mailman/listinfo/redhat-list
