[jira] [Updated] (TS-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.
[
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Giles updated TS-1073:
Attachment: (was: TS-1073.patch)
no_dns_just_forward_to_parent configuration parameter is ignored/not used.
--
Key: TS-1073
URL: https://issues.apache.org/jira/browse/TS-1073
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 3.0.2
Environment: Ubuntu 10.0, Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
Fix For: 3.1.3
I have two instances of trafficserver configured, one instance is configured
to use the second instance as a parent proxy using the following parameters
from the records.config:
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
The parent config looks like this:
dest_domain=. parent=parent:8080 round_robin=false
The no_dns_just_forward_to_parent is not used in the code and as a result dns
lookups are being performed in the child instance.
The following code changes seem to fix this:
proxy/http/HttpSM.cc
@@ -6406,11 +6405,20 @@
t_state.dns_info.lookup_success = true;
call_transact_and_set_next_state(NULL);
break;
} else if (t_state.parent_result.r == PARENT_UNDEFINED
t_state.dns_info.lookup_success) {
// Already set, and we don't have a parent proxy to lookup
ink_assert(t_state.host_db_info.ip());
Debug(dns, [HttpTransact::HandleRequest] Skipping DNS lookup,
provided by plugin);
call_transact_and_set_next_state(NULL);
break;
+ } else if (t_state.dns_info.looking_up == HttpTransact::ORIGIN_SERVER
+ t_state.http_config_param-no_dns_forward_to_parent){
+
+if(t_state.cop_test_page) {
+t_state.host_db_info.ip()
=t_state.state_machine-ua_session-get_netvc()-get_local_ip();
+}
+
+t_state.dns_info.lookup_success = true;
+call_transact_and_set_next_state(NULL);
+break;
}
HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_hostdb_lookup);
to avoid reverse ns lookups
/proxy/http/HttpTransact.cc
@@ -1650,7 +1651,8 @@
} else if (s-dns_info.lookup_name[0] = '9'
s-dns_info.lookup_name[0] = '0'
//(s-state_machine-authAdapter.needs_rev_dns() ||
- ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)) {
+ ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)
+ !s-http_config_param-no_dns_forward_to_parent) {
// note, broken logic: ACC fudges the OR stmt to always be true,
// 'AuthHttpAdapter' should do the rev-dns if needed, not here .
TRANSACT_RETURN(REVERSE_DNS_LOOKUP, HttpTransact::StartAccessControl);
I would like to have these changes applied to the repository if they look ok.
I also created an empty resolv.conf and pointed ats to the empty file:
CONFIG proxy.config.dns.resolv_conf STRING
/usr/local/etc/trafficserver/resolv.conf
When these changes are applied the child instance no longer attempts to
perform dns lookups for the
http requests that it receives. If they are not applied and the dns lookup it
slow or unreliable on the
child then the http requests are blocked by the dns lookup within the child
trafficserver instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TS-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.
[
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191126#comment-13191126
]
Kevin Giles edited comment on TS-1073 at 1/23/12 12:04 PM:
---
Apologies, it appears I had not applied the changes to the trunk, I must have
applied them elsewhere.
I have tested it against the trunk and the fix still works.
Now attaching updated patch file.
was (Author: kevin01):
Apologies, it appears I had not applied the changes to the trunk, I must
have applied them elsewhere.
I have tested it against the trunk and the fix still works.
no_dns_just_forward_to_parent configuration parameter is ignored/not used.
--
Key: TS-1073
URL: https://issues.apache.org/jira/browse/TS-1073
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 3.0.2
Environment: Ubuntu 10.0, Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
Fix For: 3.1.3
Attachments: TS-1073.patch
I have two instances of trafficserver configured, one instance is configured
to use the second instance as a parent proxy using the following parameters
from the records.config:
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
The parent config looks like this:
dest_domain=. parent=parent:8080 round_robin=false
The no_dns_just_forward_to_parent is not used in the code and as a result dns
lookups are being performed in the child instance.
The following code changes seem to fix this:
proxy/http/HttpSM.cc
@@ -6406,11 +6405,20 @@
t_state.dns_info.lookup_success = true;
call_transact_and_set_next_state(NULL);
break;
} else if (t_state.parent_result.r == PARENT_UNDEFINED
t_state.dns_info.lookup_success) {
// Already set, and we don't have a parent proxy to lookup
ink_assert(t_state.host_db_info.ip());
Debug(dns, [HttpTransact::HandleRequest] Skipping DNS lookup,
provided by plugin);
call_transact_and_set_next_state(NULL);
break;
+ } else if (t_state.dns_info.looking_up == HttpTransact::ORIGIN_SERVER
+ t_state.http_config_param-no_dns_forward_to_parent){
+
+if(t_state.cop_test_page) {
+t_state.host_db_info.ip()
=t_state.state_machine-ua_session-get_netvc()-get_local_ip();
+}
+
+t_state.dns_info.lookup_success = true;
+call_transact_and_set_next_state(NULL);
+break;
}
HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_hostdb_lookup);
to avoid reverse ns lookups
/proxy/http/HttpTransact.cc
@@ -1650,7 +1651,8 @@
} else if (s-dns_info.lookup_name[0] = '9'
s-dns_info.lookup_name[0] = '0'
//(s-state_machine-authAdapter.needs_rev_dns() ||
- ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)) {
+ ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)
+ !s-http_config_param-no_dns_forward_to_parent) {
// note, broken logic: ACC fudges the OR stmt to always be true,
// 'AuthHttpAdapter' should do the rev-dns if needed, not here .
TRANSACT_RETURN(REVERSE_DNS_LOOKUP, HttpTransact::StartAccessControl);
I would like to have these changes applied to the repository if they look ok.
I also created an empty resolv.conf and pointed ats to the empty file:
CONFIG proxy.config.dns.resolv_conf STRING
/usr/local/etc/trafficserver/resolv.conf
When these changes are applied the child instance no longer attempts to
perform dns lookups for the
http requests that it receives. If they are not applied and the dns lookup it
slow or unreliable on the
child then the http requests are blocked by the dns lookup within the child
trafficserver instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.
[
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kevin Giles updated TS-1073:
Attachment: TS-1073.patch
Apologies, it appears I had not applied the changes to the trunk, I must have
applied them elsewhere.
I have tested it against the trunk and the fix still works.
no_dns_just_forward_to_parent configuration parameter is ignored/not used.
--
Key: TS-1073
URL: https://issues.apache.org/jira/browse/TS-1073
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 3.0.2
Environment: Ubuntu 10.0, Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
Fix For: 3.1.3
Attachments: TS-1073.patch
I have two instances of trafficserver configured, one instance is configured
to use the second instance as a parent proxy using the following parameters
from the records.config:
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
The parent config looks like this:
dest_domain=. parent=parent:8080 round_robin=false
The no_dns_just_forward_to_parent is not used in the code and as a result dns
lookups are being performed in the child instance.
The following code changes seem to fix this:
proxy/http/HttpSM.cc
@@ -6406,11 +6405,20 @@
t_state.dns_info.lookup_success = true;
call_transact_and_set_next_state(NULL);
break;
} else if (t_state.parent_result.r == PARENT_UNDEFINED
t_state.dns_info.lookup_success) {
// Already set, and we don't have a parent proxy to lookup
ink_assert(t_state.host_db_info.ip());
Debug(dns, [HttpTransact::HandleRequest] Skipping DNS lookup,
provided by plugin);
call_transact_and_set_next_state(NULL);
break;
+ } else if (t_state.dns_info.looking_up == HttpTransact::ORIGIN_SERVER
+ t_state.http_config_param-no_dns_forward_to_parent){
+
+if(t_state.cop_test_page) {
+t_state.host_db_info.ip()
=t_state.state_machine-ua_session-get_netvc()-get_local_ip();
+}
+
+t_state.dns_info.lookup_success = true;
+call_transact_and_set_next_state(NULL);
+break;
}
HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_hostdb_lookup);
to avoid reverse ns lookups
/proxy/http/HttpTransact.cc
@@ -1650,7 +1651,8 @@
} else if (s-dns_info.lookup_name[0] = '9'
s-dns_info.lookup_name[0] = '0'
//(s-state_machine-authAdapter.needs_rev_dns() ||
- ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)) {
+ ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)
+ !s-http_config_param-no_dns_forward_to_parent) {
// note, broken logic: ACC fudges the OR stmt to always be true,
// 'AuthHttpAdapter' should do the rev-dns if needed, not here .
TRANSACT_RETURN(REVERSE_DNS_LOOKUP, HttpTransact::StartAccessControl);
I would like to have these changes applied to the repository if they look ok.
I also created an empty resolv.conf and pointed ats to the empty file:
CONFIG proxy.config.dns.resolv_conf STRING
/usr/local/etc/trafficserver/resolv.conf
When these changes are applied the child instance no longer attempts to
perform dns lookups for the
http requests that it receives. If they are not applied and the dns lookup it
slow or unreliable on the
child then the http requests are blocked by the dns lookup within the child
trafficserver instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1087) TSHttpTxnOutgoingAddrSet forward declaration does not match implementation
TSHttpTxnOutgoingAddrSet forward declaration does not match implementation
--
Key: TS-1087
URL: https://issues.apache.org/jira/browse/TS-1087
Project: Traffic Server
Issue Type: Bug
Components: TS API
Affects Versions: 3.1.0
Reporter: B Wyatt
Priority: Trivial
ts.h.in lists the following declaration:
{code}TSReturnCode TSHttpTxnOutgoingAddrSet(TSHttpTxn txnp, struct sockaddr
const* addr);{code}
However, the current implementation has this function sig:
{code}tsapi TSReturnCode TSHttpTxnOutgoingAddrSet(TSHttpTxn txnp, struct
sockaddr const* addr, socklen_t addrlen);{code}
Trafficserver is unable to load plugins which use this function due to the
unresolved symbol.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1077) HTTP ports cannot be configured for IPv6 and transparency.
[ https://issues.apache.org/jira/browse/TS-1077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alan M. Carroll updated TS-1077: Attachment: ts-1077.diff Fixed some tab / indenting problems. Changed frequent_accept default back to true. Changed TSNetAccept to set frequent_accept to false (required to pass regression). HTTP ports cannot be configured for IPv6 and transparency. -- Key: TS-1077 URL: https://issues.apache.org/jira/browse/TS-1077 Project: Traffic Server Issue Type: Improvement Components: HTTP Affects Versions: 3.1.1 Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: configuration, http, ipv6, ports Fix For: 3.1.3 Attachments: ts-1077.diff The syntax of records.config has IPv6 and transparency as mutually exclusive options. This should be changed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1088) Allow Per-transaction Transparency (TProxy) Override
[ https://issues.apache.org/jira/browse/TS-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B Wyatt updated TS-1088: Attachment: tsapi-allow-transparency.patch This patch adds a flag to transactions that can be poked from plugins. This flag is used to suppress the NetVCOptions::FOREIGN_ADDR binding when opening the origin server connection. Specifically assigned binds still work, only transparency is suppressed. Allow Per-transaction Transparency (TProxy) Override Key: TS-1088 URL: https://issues.apache.org/jira/browse/TS-1088 Project: Traffic Server Issue Type: New Feature Components: HTTP, TS API Affects Versions: 3.1.0 Environment: The feature was built on top of a 3.1.0 release candidate, however only minor adjustments are needed for HEAD Reporter: B Wyatt Attachments: tsapi-allow-transparency.patch Address level transparency (using TProxy) is propagated forward from the incoming connection based on global configuration. This feature allows internal and external systems that use the TS api to disable propagation on a per transaction basis. The result is that the client-proxy connection transparently appears as a client-origin server connection and the proxy-origin server connection is opaque. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1089) Allow Plugins to create transparent internal http connections
[ https://issues.apache.org/jira/browse/TS-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B Wyatt updated TS-1089: Attachment: trans-pluginvc.patch This is against a 3.1.0 rc, which means that it is not compatible with head. I am attaching it so that it can remind me or someone else to make the minor changes and submit it. Allow Plugins to create transparent internal http connections - Key: TS-1089 URL: https://issues.apache.org/jira/browse/TS-1089 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 3.1.0 Environment: This feature was built on top of a 3.1.0 release candidate. Unfortunately, it will superficially conflict with the IPv6 changes (I'm including it in case someone needs to update it before I do) Reporter: B Wyatt Attachments: trans-pluginvc.patch Plugins can create a fake connection HTTP connection into the proxy and provide a logging address. This feature allows those connections to appear to the rest of trafficsever as incoming transparent connections (such as the ones accepted by tproxy enabled installations). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1089) Allow Plugins to create transparent internal http connections
Allow Plugins to create transparent internal http connections - Key: TS-1089 URL: https://issues.apache.org/jira/browse/TS-1089 Project: Traffic Server Issue Type: New Feature Components: TS API Affects Versions: 3.1.0 Environment: This feature was built on top of a 3.1.0 release candidate. Unfortunately, it will superficially conflict with the IPv6 changes (I'm including it in case someone needs to update it before I do) Reporter: B Wyatt Attachments: trans-pluginvc.patch Plugins can create a fake connection HTTP connection into the proxy and provide a logging address. This feature allows those connections to appear to the rest of trafficsever as incoming transparent connections (such as the ones accepted by tproxy enabled installations). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1090) Configuration and plugin support for SO_MARK (on supporting platforms)
Configuration and plugin support for SO_MARK (on supporting platforms) -- Key: TS-1090 URL: https://issues.apache.org/jira/browse/TS-1090 Project: Traffic Server Issue Type: New Feature Components: HTTP, Network, TS API Reporter: B Wyatt SO_MARK allows for all packets sent out via a given socket to be pre-marked (similar to the -j MARK target in iptables, or the fwmark semantic in ip rules). This feature allows configuration to dictate SO_MARKs for accepting sockets, cluster sockets and origin server sockets independently. Additionally, plugins and internal systems can set per-transaction SO_MARKS for outgoing packets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1090) Configuration and plugin support for SO_MARK (on supporting platforms)
[ https://issues.apache.org/jira/browse/TS-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] B Wyatt updated TS-1090: Attachment: so_mark.patch This patch implements the SO_MARK feature for linux systems (that include SO_MARK in the sys/socket.h) Configuration and plugin support for SO_MARK (on supporting platforms) -- Key: TS-1090 URL: https://issues.apache.org/jira/browse/TS-1090 Project: Traffic Server Issue Type: New Feature Components: HTTP, Network, TS API Reporter: B Wyatt Attachments: so_mark.patch SO_MARK allows for all packets sent out via a given socket to be pre-marked (similar to the -j MARK target in iptables, or the fwmark semantic in ip rules). This feature allows configuration to dictate SO_MARKs for accepting sockets, cluster sockets and origin server sockets independently. Additionally, plugins and internal systems can set per-transaction SO_MARKS for outgoing packets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TS-1090) Configuration and plugin support for SO_MARK (on supporting platforms)
[ https://issues.apache.org/jira/browse/TS-1090?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191236#comment-13191236 ] B Wyatt edited comment on TS-1090 at 1/23/12 4:24 PM: -- This patch implements the SO_MARK feature for linux systems (that include SO_MARK in the sys/socket.h) EDIT: I should mention that if the autoconf script cant find the linux headers/values it needs it will disable support for this feature. So while it is cross-platform friendly, it is not cross-platform functional at this time. was (Author: wanderingbort): This patch implements the SO_MARK feature for linux systems (that include SO_MARK in the sys/socket.h) Configuration and plugin support for SO_MARK (on supporting platforms) -- Key: TS-1090 URL: https://issues.apache.org/jira/browse/TS-1090 Project: Traffic Server Issue Type: New Feature Components: HTTP, Network, TS API Reporter: B Wyatt Attachments: so_mark.patch SO_MARK allows for all packets sent out via a given socket to be pre-marked (similar to the -j MARK target in iptables, or the fwmark semantic in ip rules). This feature allows configuration to dictate SO_MARKs for accepting sockets, cluster sockets and origin server sockets independently. Additionally, plugins and internal systems can set per-transaction SO_MARKS for outgoing packets. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default -- I discovered this
while writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Abramowitz updated TS-1091:
Description:
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
was:
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default -- I discovered this
while writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could
go in the conftest.c code, but I could not find any #pragma that seemed to do
this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e
's/ -w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Abramowitz updated TS-1091:
Description:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=/usr/bin/llvm-gcc
configure: Build using CXX=/usr/bin/llvm-g++
configure: Build using CPP=/usr/bin/llvm-gcc -E
configure: Build using CFLAGS=-O3 -w -pipe -march=core2 -msse4 -g -Wall -Werror
-feliminate-unused-debug-symbols -fno-strict-aliasing
configure: Build using SHARED_CFLAGS=-fPIC
configure: Build using CXXFLAGS=-O3 -w -pipe -march=core2 -msse4 -g -Wall
-Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
-Wno-invalid-offsetof
...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
was:
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=/usr/bin/llvm-gcc
configure: Build using CXX=/usr/bin/llvm-g++
configure: Build using CPP=/usr/bin/llvm-gcc -E
configure: Build using CFLAGS=-O3 -w -pipe -march=core2 -msse4 -g -Wall
-Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
configure: Build using SHARED_CFLAGS=-fPIC
configure: Build using CXXFLAGS=-O3 -w -pipe -march=core2 -msse4 -g -Wall
-Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
-Wno-invalid-offsetof
...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does
[jira] [Updated] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Abramowitz updated TS-1091:
Description:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
was:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=/usr/bin/llvm-gcc
configure: Build using CXX=/usr/bin/llvm-g++
configure: Build using CPP=/usr/bin/llvm-gcc -E
configure: Build using CFLAGS=-O3 -w -pipe -march=core2 -msse4 -g -Wall -Werror
-feliminate-unused-debug-symbols -fno-strict-aliasing
configure: Build using SHARED_CFLAGS=-fPIC
configure: Build using CXXFLAGS=-O3 -w -pipe -march=core2 -msse4 -g -Wall
-Werror -feliminate-unused-debug-symbols -fno-strict-aliasing
-Wno-invalid-offsetof
...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell
[jira] [Updated] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Abramowitz updated TS-1091:
Description:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini |
grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
was:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying
[jira] [Updated] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Abramowitz updated TS-1091:
Description:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini |
grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
was:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini |
grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
[jira] [Commented] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191256#comment-13191256
]
Leif Hedstrom commented on TS-1091:
---
Would it not be possible to make a regex that captures all the cases? Perhaps
something like (untested)
s/ *-w */ /g
? It means we might have an additional whitespace in the CFLAGs, but that seems
ok :).
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could
go in the conftest.c code, but I could not find any #pragma that seemed to do
this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e
's/ -w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191256#comment-13191256
]
Leif Hedstrom edited comment on TS-1091 at 1/23/12 5:06 PM:
Would it not be possible to make a regex that captures all the cases? Perhaps
something like (untested)
{code}
s/ *-w */ /g
{code}
? It means we might have an additional whitespace in the CFLAGs, but that seems
ok :).
was (Author: zwoop):
Would it not be possible to make a regex that captures all the cases?
Perhaps something like (untested)
s/ *-w */ /g
? It means we might have an additional whitespace in the CFLAGs, but that seems
ok :).
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could
go in the conftest.c code, but I could not find any #pragma that seemed to do
this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e
's/ -w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Abramowitz updated TS-1091:
Description:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini |
grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing
...
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
gethostbyname_r_glibc2 = 1
gethostbyname_r_hostent_data = 1
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
...
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7' to
'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int, int*)'
make[3]: *** [ink_inet.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
{code}
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
was:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini |
grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing...
{code}
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc
[jira] [Updated] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marc Abramowitz updated TS-1091:
Description:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini |
grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing
...
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
gethostbyname_r_glibc2 = 1
gethostbyname_r_hostent_data = 1
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
...
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7' to
'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int, int*)'
make[3]: *** [ink_inet.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
{code}
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code
(http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html looked promising but
I could not find one that worked), but I could not find any #pragma that seemed
to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/
-w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
was:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini |
grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing
...
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
gethostbyname_r_glibc2 = 1
gethostbyname_r_hostent_data = 1
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
...
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7' to
'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int, int*)'
make[3]: *** [ink_inet.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
{code}
Arguably, people should never run configure with CFLAGS=-w and this might seem
stupid and something that should never happen, but it turns out that Homebrew
(http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and all
is well, but I thought it would be interesting to make Traffic Server resistant
to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could go
in the conftest.c code, but I could not find any #pragma that seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+
[jira] [Updated] (TS-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.
[
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1073:
--
Fix Version/s: (was: 3.1.3)
3.1.2
no_dns_just_forward_to_parent configuration parameter is ignored/not used.
--
Key: TS-1073
URL: https://issues.apache.org/jira/browse/TS-1073
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 3.0.2
Environment: Ubuntu 10.0, Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
Fix For: 3.1.2
Attachments: TS-1073.patch
I have two instances of trafficserver configured, one instance is configured
to use the second instance as a parent proxy using the following parameters
from the records.config:
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
The parent config looks like this:
dest_domain=. parent=parent:8080 round_robin=false
The no_dns_just_forward_to_parent is not used in the code and as a result dns
lookups are being performed in the child instance.
The following code changes seem to fix this:
proxy/http/HttpSM.cc
@@ -6406,11 +6405,20 @@
t_state.dns_info.lookup_success = true;
call_transact_and_set_next_state(NULL);
break;
} else if (t_state.parent_result.r == PARENT_UNDEFINED
t_state.dns_info.lookup_success) {
// Already set, and we don't have a parent proxy to lookup
ink_assert(t_state.host_db_info.ip());
Debug(dns, [HttpTransact::HandleRequest] Skipping DNS lookup,
provided by plugin);
call_transact_and_set_next_state(NULL);
break;
+ } else if (t_state.dns_info.looking_up == HttpTransact::ORIGIN_SERVER
+ t_state.http_config_param-no_dns_forward_to_parent){
+
+if(t_state.cop_test_page) {
+t_state.host_db_info.ip()
=t_state.state_machine-ua_session-get_netvc()-get_local_ip();
+}
+
+t_state.dns_info.lookup_success = true;
+call_transact_and_set_next_state(NULL);
+break;
}
HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_hostdb_lookup);
to avoid reverse ns lookups
/proxy/http/HttpTransact.cc
@@ -1650,7 +1651,8 @@
} else if (s-dns_info.lookup_name[0] = '9'
s-dns_info.lookup_name[0] = '0'
//(s-state_machine-authAdapter.needs_rev_dns() ||
- ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)) {
+ ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)
+ !s-http_config_param-no_dns_forward_to_parent) {
// note, broken logic: ACC fudges the OR stmt to always be true,
// 'AuthHttpAdapter' should do the rev-dns if needed, not here .
TRANSACT_RETURN(REVERSE_DNS_LOOKUP, HttpTransact::StartAccessControl);
I would like to have these changes applied to the repository if they look ok.
I also created an empty resolv.conf and pointed ats to the empty file:
CONFIG proxy.config.dns.resolv_conf STRING
/usr/local/etc/trafficserver/resolv.conf
When these changes are applied the child instance no longer attempts to
perform dns lookups for the
http requests that it receives. If they are not applied and the dns lookup it
slow or unreliable on the
child then the http requests are blocked by the dns lookup within the child
trafficserver instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191267#comment-13191267
]
Marc Abramowitz commented on TS-1091:
-
Hey Leif,
Yeah I really wanted to get it into a single regex, but it escaped me. The
tricky part is handling -w at the beginning or end of CFLAGS. My instinct was
to use \b-w\b but I don't think we can rely on sed (especially non-GNU sed)
to support \b. Your regex looks like it will work though:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -Werror -w -O3 | sed
's/ *-w */ /g'
-Wall -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -Werror -O3 -w | sed
's/ *-w */ /g'
-Wall -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -w -Wall -Werror -O3 | sed
's/ *-w */ /g'
-Wall -Werror -O3
{code}
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing
...
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
gethostbyname_r_glibc2 = 1
gethostbyname_r_hostent_data = 1
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
...
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7'
to 'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int,
int*)'
make[3]: *** [ink_inet.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could
go in the conftest.c code
(http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html looked promising
but I could not find one that worked), but I could not find any #pragma that
seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e
's/ -w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191267#comment-13191267
]
Marc Abramowitz edited comment on TS-1091 at 1/23/12 5:23 PM:
--
Hey Leif,
Yeah I really wanted to get it into a single regex, but it escaped me. The
tricky part is handling -w at the beginning or end of CFLAGS. My instinct was
to use \b-w\b but I don't think we can rely on sed (especially non-GNU sed)
to support \b. Your regex looks like it will work though:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -Werror -w -O3 | sed
's/ *-w */ /g'
-Wall -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -Werror -O3 -w | sed
's/ *-w */ /g'
-Wall -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -w -Wall -Werror -O3 | sed
's/ *-w */ /g'
-Wall -Werror -O3
{code}
except here's one fake case that fails:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -fake-option-w -Werror
-O3 | sed 's/ *-w */ /g'
-Wall -fake-option -Werror -O3
{code}
I don't know if there are any gcc options that actually end in -w though. :-)
was (Author: msabramo):
Hey Leif,
Yeah I really wanted to get it into a single regex, but it escaped me. The
tricky part is handling -w at the beginning or end of CFLAGS. My instinct was
to use \b-w\b but I don't think we can rely on sed (especially non-GNU sed)
to support \b. Your regex looks like it will work though:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -Werror -w -O3 | sed
's/ *-w */ /g'
-Wall -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -Werror -O3 -w | sed
's/ *-w */ /g'
-Wall -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -w -Wall -Werror -O3 | sed
's/ *-w */ /g'
-Wall -Werror -O3
{code}
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing
...
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
gethostbyname_r_glibc2 = 1
gethostbyname_r_hostent_data = 1
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
...
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7'
to 'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int,
int*)'
make[3]: *** [ink_inet.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could
go in the conftest.c code
(http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html looked promising
but I could not find one that worked), but I could not find any #pragma that
seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
[jira] [Commented] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191273#comment-13191273
]
Marc Abramowitz commented on TS-1091:
-
Here's an actual possible case that fails:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -mno-wide-multiply
-Werror -O3 | sed 's/ *-w */ /g'
-Wall -mno ide-multiply -Werror -O3
{code}
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing
...
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
gethostbyname_r_glibc2 = 1
gethostbyname_r_hostent_data = 1
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
...
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7'
to 'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int,
int*)'
make[3]: *** [ink_inet.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could
go in the conftest.c code
(http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html looked promising
but I could not find one that worked), but I could not find any #pragma that
seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e
's/ -w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191273#comment-13191273
]
Marc Abramowitz edited comment on TS-1091 at 1/23/12 5:27 PM:
--
Here's an actual possible case that fails:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -mno-wide-multiply
-Werror -O3 | sed 's/ *-w */ /g'
-Wall -mno ide-multiply -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -mno-wide-multiply
-Werror -O3 | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/ -w / /'
-Wall -mno-wide-multiply -Werror -O3
{code}
was (Author: msabramo):
Here's an actual possible case that fails:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -mno-wide-multiply
-Werror -O3 | sed 's/ *-w */ /g'
-Wall -mno ide-multiply -Werror -O3
{code}
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing
...
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
gethostbyname_r_glibc2 = 1
gethostbyname_r_hostent_data = 1
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
...
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7'
to 'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int,
int*)'
make[3]: *** [ink_inet.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could
go in the conftest.c code
(http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html looked promising
but I could not find one that worked), but I could not find any #pragma that
seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e
's/ -w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (TS-1073) no_dns_just_forward_to_parent configuration parameter is ignored/not used.
[
https://issues.apache.org/jira/browse/TS-1073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191276#comment-13191276
]
Leif Hedstrom commented on TS-1073:
---
Sorry to be a pain here, but should we not try to be IPv6 compatible here ?
Perhaps it could be e.g.
{code}
+if (t_state.cop_test_page)
+ ink_inet_copy(t_state.host_db_info.ip(),
t_state.state_machine-ua_session-get_netvc()-get_local_addr());
{code}
Or, are the COP test pages always guaranteed to be IPv4 only (not sure how that
works, but even so, at some point, I imagine IPv4 will go away completely :).
Thoughts?
no_dns_just_forward_to_parent configuration parameter is ignored/not used.
--
Key: TS-1073
URL: https://issues.apache.org/jira/browse/TS-1073
Project: Traffic Server
Issue Type: Bug
Components: DNS
Affects Versions: 3.0.2
Environment: Ubuntu 10.0, Fedora 14
Reporter: Kevin Giles
Assignee: Leif Hedstrom
Fix For: 3.1.2
Attachments: TS-1073.patch
I have two instances of trafficserver configured, one instance is configured
to use the second instance as a parent proxy using the following parameters
from the records.config:
CONFIG proxy.config.http.no_dns_just_forward_to_parent INT 1
CONFIG proxy.config.http.parent_proxy_routing_enable INT 1
The parent config looks like this:
dest_domain=. parent=parent:8080 round_robin=false
The no_dns_just_forward_to_parent is not used in the code and as a result dns
lookups are being performed in the child instance.
The following code changes seem to fix this:
proxy/http/HttpSM.cc
@@ -6406,11 +6405,20 @@
t_state.dns_info.lookup_success = true;
call_transact_and_set_next_state(NULL);
break;
} else if (t_state.parent_result.r == PARENT_UNDEFINED
t_state.dns_info.lookup_success) {
// Already set, and we don't have a parent proxy to lookup
ink_assert(t_state.host_db_info.ip());
Debug(dns, [HttpTransact::HandleRequest] Skipping DNS lookup,
provided by plugin);
call_transact_and_set_next_state(NULL);
break;
+ } else if (t_state.dns_info.looking_up == HttpTransact::ORIGIN_SERVER
+ t_state.http_config_param-no_dns_forward_to_parent){
+
+if(t_state.cop_test_page) {
+t_state.host_db_info.ip()
=t_state.state_machine-ua_session-get_netvc()-get_local_ip();
+}
+
+t_state.dns_info.lookup_success = true;
+call_transact_and_set_next_state(NULL);
+break;
}
HTTP_SM_SET_DEFAULT_HANDLER(HttpSM::state_hostdb_lookup);
to avoid reverse ns lookups
/proxy/http/HttpTransact.cc
@@ -1650,7 +1651,8 @@
} else if (s-dns_info.lookup_name[0] = '9'
s-dns_info.lookup_name[0] = '0'
//(s-state_machine-authAdapter.needs_rev_dns() ||
- ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)) {
+ ( host_rule_in_CacheControlTable() ||
s-parent_params-ParentTable-hostMatch)
+ !s-http_config_param-no_dns_forward_to_parent) {
// note, broken logic: ACC fudges the OR stmt to always be true,
// 'AuthHttpAdapter' should do the rev-dns if needed, not here .
TRANSACT_RETURN(REVERSE_DNS_LOOKUP, HttpTransact::StartAccessControl);
I would like to have these changes applied to the repository if they look ok.
I also created an empty resolv.conf and pointed ats to the empty file:
CONFIG proxy.config.dns.resolv_conf STRING
/usr/local/etc/trafficserver/resolv.conf
When these changes are applied the child instance no longer attempts to
perform dns lookups for the
http requests that it receives. If they are not applied and the dns lookup it
slow or unreliable on the
child then the http requests are blocked by the dns lookup within the child
trafficserver instance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191273#comment-13191273
]
Marc Abramowitz edited comment on TS-1091 at 1/23/12 5:41 PM:
--
Here's an actual possible case that fails:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -mno-wide-multiply
-Werror -O3 | sed 's/ *-w */ /g'
-Wall -mno ide-multiply -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -mno-wide-multiply
-Werror -O3 | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/ -w / /'
-Wall -mno-wide-multiply -Werror -O3
{code}
Some problematic options that have -w in them:
{code}
-fno-weak
-whyload
-weak_reference_mismatches
-whatsloaded
-mno-wide-multiply
-fshort-wchar
-x assembler-with-cpp
{code}
These get battered by the simpler regex:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -fno-weak -Werror -O3
| sed 's/ *-w */ /g'
-Wall -fno eak -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -whyload -Werror -O3 |
sed 's/ *-w */ /g'
-Wall hyload -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -whatsloaded -Werror
-O3 | sed 's/ *-w */ /g'
-Wall hatsloaded -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -fshort-wchar -Werror
-O3 | sed 's/ *-w */ /g'
-Wall -fshort char -Werror -O3
{code}
was (Author: msabramo):
Here's an actual possible case that fails:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -mno-wide-multiply
-Werror -O3 | sed 's/ *-w */ /g'
-Wall -mno ide-multiply -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -mno-wide-multiply
-Werror -O3 | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/ -w / /'
-Wall -mno-wide-multiply -Werror -O3
{code}
Some problematic options that have -w in them:
{code}
-fno-weak
-whyload
-weak_reference_mismatches
-whatsloaded
-mno-wide-multiply
-fshort-wchar
-x assembler-with-cpp
{code}
These get battered by the simpler regex:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -fno-weak -Werror -O3
| sed 's/ *-w */ /g'
-Wall -fno eak -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -whyload -Werror -O3 |
sed 's/ *-w */ /g'
-Wall hyload -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -whatsloaded -Werror
-O3 | sed 's/ *-w */ /g'
-Wall hatsloaded -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -fshort-wchar -Werror
-O3 | sed 's/ *-w */ /g'
-Wall -fshort char -Werror -O3
{code}
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing
...
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
gethostbyname_r_glibc2 = 1
gethostbyname_r_hostent_data = 1
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
...
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7'
to 'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int,
int*)'
make[3]: *** [ink_inet.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this
[jira] [Issue Comment Edited] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191267#comment-13191267
]
Marc Abramowitz edited comment on TS-1091 at 1/23/12 5:41 PM:
--
Hey Leif,
Yeah I really wanted to get it into a single regex, but it escaped me. The
tricky part is handling -w at the beginning or end of CFLAGS. My instinct was
to use \b-w\b but I don't think we can rely on sed (especially non-GNU sed)
to support \b. Your regex looks like it will work though:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -Werror -w -O3 | sed
's/ *-w */ /g'
-Wall -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -Werror -O3 -w | sed
's/ *-w */ /g'
-Wall -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -w -Wall -Werror -O3 | sed
's/ *-w */ /g'
-Wall -Werror -O3
{code}
except here's one (contrived) case that fails:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -fake-option-w -Werror
-O3 | sed 's/ *-w */ /g'
-Wall -fake-option -Werror -O3
{code}
was (Author: msabramo):
Hey Leif,
Yeah I really wanted to get it into a single regex, but it escaped me. The
tricky part is handling -w at the beginning or end of CFLAGS. My instinct was
to use \b-w\b but I don't think we can rely on sed (especially non-GNU sed)
to support \b. Your regex looks like it will work though:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -Werror -w -O3 | sed
's/ *-w */ /g'
-Wall -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -Werror -O3 -w | sed
's/ *-w */ /g'
-Wall -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -w -Wall -Werror -O3 | sed
's/ *-w */ /g'
-Wall -Werror -O3
{code}
except here's one (contrived) case that fails:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -fake-option-w -Werror
-O3 | sed 's/ *-w */ /g'
-Wall -fake-option -Werror -O3
{code}
I don't know if there are any gcc options that actually end in -w though. :-)
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing
...
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
gethostbyname_r_glibc2 = 1
gethostbyname_r_hostent_data = 1
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
...
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7'
to 'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int,
int*)'
make[3]: *** [ink_inet.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could
go in the conftest.c code
(http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html looked promising
but I could not find one that worked), but I could not find any #pragma that
seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
[jira] [Issue Comment Edited] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191273#comment-13191273
]
Marc Abramowitz edited comment on TS-1091 at 1/23/12 5:40 PM:
--
Here's an actual possible case that fails:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -mno-wide-multiply
-Werror -O3 | sed 's/ *-w */ /g'
-Wall -mno ide-multiply -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -mno-wide-multiply
-Werror -O3 | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/ -w / /'
-Wall -mno-wide-multiply -Werror -O3
{code}
Some problematic options that have -w in them:
{code}
-fno-weak
-whyload
-weak_reference_mismatches
-whatsloaded
-mno-wide-multiply
-fshort-wchar
-x assembler-with-cpp
{code}
These get battered by the simpler regex:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -fno-weak -Werror -O3
| sed 's/ *-w */ /g'
-Wall -fno eak -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -whyload -Werror -O3 |
sed 's/ *-w */ /g'
-Wall hyload -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -whatsloaded -Werror
-O3 | sed 's/ *-w */ /g'
-Wall hatsloaded -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -fshort-wchar -Werror
-O3 | sed 's/ *-w */ /g'
-Wall -fshort char -Werror -O3
{code}
was (Author: msabramo):
Here's an actual possible case that fails:
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -mno-wide-multiply
-Werror -O3 | sed 's/ *-w */ /g'
-Wall -mno ide-multiply -Werror -O3
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ echo -Wall -mno-wide-multiply
-Werror -O3 | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e 's/ -w / /'
-Wall -mno-wide-multiply -Werror -O3
{code}
Some problematic options that have -w in them:
-fno-weak
-whyload
-weak_reference_mismatches
-whatsloaded
-mno-wide-multiply
-fshort-wchar
-x assembler-with-cpp
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing
...
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
gethostbyname_r_glibc2 = 1
gethostbyname_r_hostent_data = 1
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
...
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7'
to 'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int,
int*)'
make[3]: *** [ink_inet.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could
go in the conftest.c code
(http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html looked promising
but I could not find one that worked), but I could not find any #pragma that
seemed to do this.
I ended up making a small change to
[jira] [Commented] (TS-1091) `./configure CFLAGS=-w` causes configure script to wrongly guess style of `gethostbyname_r` on OS X (and probably other BSDs)
[
https://issues.apache.org/jira/browse/TS-1091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13191429#comment-13191429
]
Marc Abramowitz commented on TS-1091:
-
Or a more extreme change would be to use an existing autoconf macro for this:
http://www.gnu.org/software/autoconf-archive/ax_func_which_gethostbyname_r.html
This one takes a different approach - it does a sanity check where it tries to
compile with a one arg gethostbyname_r which doesn't exist so if that passes,
then it knows something is wrong.
`./configure CFLAGS=-w` causes configure script to wrongly guess style of
`gethostbyname_r` on OS X (and probably other BSDs)
-
Key: TS-1091
URL: https://issues.apache.org/jira/browse/TS-1091
Project: Traffic Server
Issue Type: Bug
Components: Build
Affects Versions: 3.0.2
Environment: OS X 10.6.8
Reporter: Marc Abramowitz
Priority: Minor
Labels: autoconf, build, configure
Original Estimate: 10m
Remaining Estimate: 10m
{code}
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ system_profiler -detailLevel mini
| grep 'System Version'
System Version: Mac OS X 10.6.8 (10K549)
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ ./configure CFLAGS=-w
...
checking style of gethostbyname_r routine... glibc2
checking 3rd argument to the gethostbyname_r routines... hostent_data
configure: Build using CC=gcc
configure: Build using CXX=g++
configure: Build using CPP=gcc -E
configure: Build using CFLAGS=-w -g -pipe -Wall -Werror -O3
-feliminate-unused-debug-symbols -fno-strict-aliasing
...
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ grep gethostbyname_r Makefile
gethostbyname_r_glibc2 = 1
gethostbyname_r_hostent_data = 1
marca@SCML-MarcA:~/src/trafficserver-3.0.2$ make
...
ink_inet.cc: In function 'hostent* ink_gethostbyaddr_r(char*, int, int,
ink_gethostbyaddr_r_data*)':
ink_inet.cc:73: error: cannot convert 'hostent**' to 'int*' for argument '7'
to 'hostent* gethostbyaddr_r(const char*, size_t, int, hostent*, char*, int,
int*)'
make[3]: *** [ink_inet.lo] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all-recursive] Error 1
{code}
Arguably, people should never run configure with CFLAGS=-w and this might
seem stupid and something that should never happen, but it turns out that
Homebrew (http://mxcl.github.com/homebrew/) does this by default
(https://github.com/mxcl/homebrew/issues/9728) -- I discovered this while
writing a Homebrew formula for Traffic Server
(https://github.com/mxcl/homebrew/pull/9513). After discovering that this was
causing problems, I modified my formula to tell Homebrew not to do this and
all is well, but I thought it would be interesting to make Traffic Server
resistant to this as well.
I first tried to enable warnings by trying to find a gcc #pragma that could
go in the conftest.c code
(http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html looked promising
but I could not find one that worked), but I could not find any #pragma that
seemed to do this.
I ended up making a small change to `build/common.m4` that strips -w out of
CFLAGS using `sed`.
{code}
--- build/common.m4.2012-01-22-092051 2011-05-25 13:19:54.0 -0700
+++ build/common.m4 2012-01-22 22:48:14.0 -0800
@@ -177,6 +177,7 @@
if test $ac_cv_prog_gcc = yes; then
CFLAGS=$CFLAGS -Werror
fi
+ CFLAGS=$(echo $CFLAGS | sed -e 's/^-w$//' -e 's/^-w //' -e 's/ -w$//' -e
's/ -w / /')
AC_COMPILE_IFELSE([AC_LANG_SOURCE([
[#include confdefs.h
]
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
