Re: HTTPD 2.1 (Head) Build issues for NetWare...
On Thu, Jun 16, 2005 at 08:43:00AM -0600, Brad Nicholes wrote: I have run into this one also and I still don't understand why the make is all of the sudden asking for yacc when this all worked before. Since neither mod_ssl nor BSD sockets are part of the standard NetWare build, this isn't a show stopper. But I would like to understand what happened and how to fix it. You should get the Netware build to touch the generated files (or equivalent) as buildconf does on Unix. This sequence will ensure that make never regenerates the shipped files: echo fixing timestamps for mod_ssl sources cd modules/ssl touch ssl_expr_parse.y sleep 1 touch ssl_expr_parse.c ssl_expr_parse.h ssl_expr_scan.l sleep 1 touch ssl_expr_scan.c cd ../.. Regards, joe
Re: HTTPD 2.1 (Head) Build issues for NetWare...
At 11:25 AM 6/16/2005, Greg Marr wrote: At 12:01 PM 6/16/2005, William A. Rowe, Jr. wrote: Back to httpd land; the question is --- is this the right choice for *our tarballs*? Which may or may not be related to the question above. In any case; this is useful metadata even for end users who build the package for the reasons I mentioned; does anyone have a desire/justification to lose the commit dates and use the RM's checkout date? It seems to me that modification or commit date/time is the right choice for *tarballs*. Ok. Other folks have thoughts about this? Checkout date/time is generally the right choice for developers, because otherwise make doesn't always pick up when a file has changed. (I've been bit by the Visual SourceSafe modification time default enough times.) Although - heh - you are assuming the order of the checked out files happen to be stacked so that the dependency happens to be a fraction of a second older than the target :) To clarify, the last tarballs WERE checkout/export time stamped. Bill
Re: HTTPD 2.1 (Head) Build issues for NetWare...
At 10:42 AM 6/17/2005, William A. Rowe, Jr. wrote: Checkout date/time is generally the right choice for developers, because otherwise make doesn't always pick up when a file has changed. (I've been bit by the Visual SourceSafe modification time default enough times.) Although - heh - you are assuming the order of the checked out files happen to be stacked so that the dependency happens to be a fraction of a second older than the target :) Actually, I'm assuming that there are no checked in files that are dependents of other checked in files, (no generated files ever checked in) since that's also asking for trouble (been there, done that).
HTTPD 2.1 (Head) Build issues for NetWare...
Greetings All, Trying to build Apache 2.1 (head) for NetWare on a Win2K box and get the following error: Compiling ssl_expr.c Compiling ssl_expr_eval.c process_begin: CreateProcess((null), yacc ssl_expr_parse.y, ...) failed. make (e=2): The system cannot find the file specified. make[2]: *** [ssl_expr_parse.c] Error 2 make[1]: *** [ssl] Error 2 make: *** [modules] Error 2 Hopefully this is a bug and I don't need another cygwin tool?... Using OpenSSl 0.9.7g and WinSockets... If I set USE_STDSOCKETS=1 I then get a failure building logresolve: Generating Release.o\logres_link.opt Linking Release.o/logres.nlm ### mwldnlm Linker Error: # Undefined symbol: 'WS2_32_gethostbyaddr' # referenced from 'cgethost' in logresolve.o ### mwldnlm Linker Error: # Undefined symbol: 'WSAGetLastError' # referenced from 'cgethost' in logresolve.o # referenced from 'cgethost' in logresolve.o # referenced from 'cgethost' in logresolve.o ### mwldnlm Linker Error: # Undefined symbol: 'WS2_32_inet_ntoa' # referenced from 'cgethost' in logresolve.o # referenced from 'cgethost' in logresolve.o # referenced from 'stats' in logresolve.o # referenced from 'cgethost' in logresolve.o ### mwldnlm Linker Error: # Undefined symbol: 'WS2_32_gethostbyname' # referenced from 'cgethost' in logresolve.o ### mwldnlm Linker Error: # Undefined symbol: 'WS2_32_inet_addr' # referenced from 'main' in logresolve.o Errors caused tool to abort. I can't even build APR with the June'05 LibC but that's another story. Regards, Norm
Re: HTTPD 2.1 (Head) Build issues for NetWare...
I have run into this one also and I still don't understand why the make is all of the sudden asking for yacc when this all worked before. Since neither mod_ssl nor BSD sockets are part of the standard NetWare build, this isn't a show stopper. But I would like to understand what happened and how to fix it. Brad [EMAIL PROTECTED] Thursday, June 16, 2005 3:53:35 AM Greetings All, Trying to build Apache 2.1 (head) for NetWare on a Win2K box and get the following error: Compiling ssl_expr.c Compiling ssl_expr_eval.c process_begin: CreateProcess((null), yacc ssl_expr_parse.y, ...) failed. make (e=2): The system cannot find the file specified. make[2]: *** [ssl_expr_parse.c] Error 2 make[1]: *** [ssl] Error 2 make: *** [modules] Error 2 Hopefully this is a bug and I don't need another cygwin tool?... Using OpenSSl 0.9.7g and WinSockets... If I set USE_STDSOCKETS=1 I then get a failure building logresolve: Generating Release.o\logres_link.opt Linking Release.o/logres.nlm ### mwldnlm Linker Error: # Undefined symbol: 'WS2_32_gethostbyaddr' # referenced from 'cgethost' in logresolve.o ### mwldnlm Linker Error: # Undefined symbol: 'WSAGetLastError' # referenced from 'cgethost' in logresolve.o # referenced from 'cgethost' in logresolve.o # referenced from 'cgethost' in logresolve.o ### mwldnlm Linker Error: # Undefined symbol: 'WS2_32_inet_ntoa' # referenced from 'cgethost' in logresolve.o # referenced from 'cgethost' in logresolve.o # referenced from 'stats' in logresolve.o # referenced from 'cgethost' in logresolve.o ### mwldnlm Linker Error: # Undefined symbol: 'WS2_32_gethostbyname' # referenced from 'cgethost' in logresolve.o ### mwldnlm Linker Error: # Undefined symbol: 'WS2_32_inet_addr' # referenced from 'main' in logresolve.o Errors caused tool to abort. I can't even build APR with the June'05 LibC but that's another story. Regards, Norm
Re: HTTPD 2.1 (Head) Build issues for NetWare...
At 09:43 AM 6/16/2005, Brad Nicholes wrote: I have run into this one also and I still don't understand why the make is all of the sudden asking for yacc when this all worked before. Since neither mod_ssl nor BSD sockets are part of the standard NetWare build, this isn't a show stopper. But I would like to understand what happened and how to fix it. If I had to guess; * The most recent tarballs have been pulled together with SVN's absolutely bogus default of [miscellany] use-commit-times = no (see your ~/.svn/config, where you can uncomment this section and option). This means they are checkout dates, which are entirely useless. It means any dependencies that WOULD be resolved by our commit order are no longer resolved and force rebuilds. * There was an extra 'touch' to the datestamps for these files at one time; this may not have occurred in the last package. * Depending on the tool used to unpack the source tarball, that tool might not be date preserving; this would invalidate anything we attempted above to prevent rebuilding these targets.
Re: HTTPD 2.1 (Head) Build issues for NetWare...
William A. Rowe, Jr. wrote: At 09:43 AM 6/16/2005, Brad Nicholes wrote: I have run into this one also and I still don't understand why the make is all of the sudden asking for yacc when this all worked before. Since neither mod_ssl nor BSD sockets are part of the standard NetWare build, this isn't a show stopper. But I would like to understand what happened and how to fix it. If I had to guess; * The most recent tarballs have been pulled together with SVN's absolutely bogus default of [miscellany] use-commit-times = no (see your ~/.svn/config, where you can uncomment this section and option). Bill, I wish you would stop calling things bogus without doing the research why this is the default. This means they are checkout dates, which are entirely useless. It means any dependencies that WOULD be resolved by our commit order are no longer resolved and force rebuilds. * There was an extra 'touch' to the datestamps for these files at one time; this may not have occurred in the last package. The scripts in httpd-dist/ to create the packages most certainly do touch the files. * Depending on the tool used to unpack the source tarball, that tool might not be date preserving; this would invalidate anything we attempted above to prevent rebuilding these targets. Sander
Re: HTTPD 2.1 (Head) Build issues for NetWare...
At 09:59 AM 6/16/2005, Sander Striker wrote: William A. Rowe, Jr. wrote: * The most recent tarballs have been pulled together with SVN's absolutely bogus default of [miscellany] use-commit-times = no (see your ~/.svn/config, where you can uncomment this section and option). Bill, I wish you would stop calling things bogus without doing the research why this is the default. That's reasonable; does anyone want to point me to the thread that justified this as the best-choice default? [I suspect I asked about this once before.] Back to httpd land; the question is --- is this the right choice for *our tarballs*? Which may or may not be related to the question above. In any case; this is useful metadata even for end users who build the package for the reasons I mentioned; does anyone have a desire/justification to lose the commit dates and use the RM's checkout date? Bill
Re: HTTPD 2.1 (Head) Build issues for NetWare...
Greetings All Good Morning from Au. I'm currently using the SVN 1.2 TortoiseSVN client (upgraded a few days ago), and noted the following dates in modules/ssl - ssl_expr_parse.h 12/11/04 ssl_expr_parse.c 12/02/05 ssl_expr_parse.y 15/06/05 ssl_expr_scan.c5/02/05 ssl_expr_scan.l 15/06/05 From this it is hardly surprising that yacc is wanted to run. However, by deleting the above files and running the SVN client again, all the above files are replaced and given todays date and time, and hence I suspect Make will be happy enough to live without yacc. No idea what the 'default' was on the previous TortoiseSVN client but the present release sets the local file date/time as 'local' but has the option to set it to 'last commit time'... if I set the flag, then the dates are pretty much restored as noted above. HTH, Norm Sander Striker wrote: William A. Rowe, Jr. wrote: At 09:59 AM 6/16/2005, Sander Striker wrote: William A. Rowe, Jr. wrote: * The most recent tarballs have been pulled together with SVN's absolutely bogus default of [miscellany] use-commit-times = no (see your ~/.svn/config, where you can uncomment this section and option). Bill, I wish you would stop calling things bogus without doing the research why this is the default. That's reasonable; does anyone want to point me to the thread that justified this as the best-choice default? [I suspect I asked about this once before.] I remember it was a long one, but I don't have a pointer handy at this point. Back to httpd land; the question is --- is this the right choice for *our tarballs*? Which may or may not be related to the question above. In any case; this is useful metadata even for end users who build the package for the reasons I mentioned; does anyone have a desire/justification to lose the commit dates and use the RM's checkout date? Note that the scripts use svn export. IIRC that does default to use the last commit time, but I could be wrong. Sander .
Re: HTTPD 2.1 (Head) Build issues for NetWare...
William A. Rowe, Jr. wrote: At 09:59 AM 6/16/2005, Sander Striker wrote: William A. Rowe, Jr. wrote: * The most recent tarballs have been pulled together with SVN's absolutely bogus default of [miscellany] use-commit-times = no (see your ~/.svn/config, where you can uncomment this section and option). Bill, I wish you would stop calling things bogus without doing the research why this is the default. That's reasonable; does anyone want to point me to the thread that justified this as the best-choice default? [I suspect I asked about this once before.] I remember it was a long one, but I don't have a pointer handy at this point. Back to httpd land; the question is --- is this the right choice for *our tarballs*? Which may or may not be related to the question above. In any case; this is useful metadata even for end users who build the package for the reasons I mentioned; does anyone have a desire/justification to lose the commit dates and use the RM's checkout date? Note that the scripts use svn export. IIRC that does default to use the last commit time, but I could be wrong. Sander
