Matthias Andree said the following on 7/11/06 1:48 PM:
Atanas <[EMAIL PROTECTED]> writes:
Recent portupgrade versions no longer obey the -M command line switch,
i.e. any optional arguments to be prepended to each make command.
How to reproduce:
# portinstall -M "APACHE_HARD_SERVER_LIMIT=1024" www/apache13
...
===> src/ap
cc -c -I../os/unix -I../include -I/usr/local/include -funsigned-char
-O2 -fno-strict-aliasing -pipe
-DDOCUMENT_LOCATION=\"/usr/local/www/data\"
-DDEFAULT_PATH=\"/bin:/usr/bin:/usr/local/bin\" -DHARD_SERVER_LIMIT=512
`../apaci` ap_cpystrn.c
...
Note the -DHARD_SERVER_LIMIT=512 above.
Does it work if you type (you can omit the env in /bin/sh, bash, (pd)ksh
and other Bourne-like shells):
env APACHE_HARD_SERVER_LIMIT=1024 portinstall www/apache13
Of course it would, but this just bypasses the problem. There are other
ways to work this around as well - like not using portupgrade at all and
building everything with make.
The problem is that there's a bug introduced by some of the recent
portupgrade versions that changes its documented behavior. The '-M'
switch in partucular no longer works, thus causing any existing
port/package installation scripts depending on that switch to build
packages with incorrect optional parameters.
It's not a problem with a particular port. The www/apache13 port was
given just as example how to reproduce the bug.
This affects _all_ ports when installed/upgraded/built via portupgrade
and when the '-M' switch is used.
(Isn't it time to migrate to a newer Apache version anyways? 8-) )
(This is a long subject and kind of off-topic here. My short answer is
no, or not yet. In some environments there are still legitimate reasons
to use 1.3)
Regards,
Atanas
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"