Discussion:
[Vote] Release APR 1.2.9/0.9.14 and apr-iconv 1.2.0
(too old to reply)
William A. Rowe, Jr.
2007-06-04 22:49:43 UTC
Permalink
http://apr.apache.org/dev/dist/

+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0

Three packages so far to consider, votes welcome
Brad Nicholes
2007-06-05 19:35:30 UTC
Permalink
Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ +1 ] apr-0.9.14
[ +1 ] apr-1.2.9
[ na ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
NetWare

Brad
Bojan Smojver
2007-06-05 23:38:32 UTC
Permalink
Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
APR Compiles and passes tests when built as an RPM on Fedora 7, i386. On
x86_64, I get:
--------------------------------------
testlfs : Line 265: Large Files not supported
SUCCESS
--------------------------------------

Something isn't right here. I'm pretty sure Fedora 7 on x86_64 has large
file support and yet APR_HAS_LARGE_FILES gets set to zero.
--
Bojan
Bojan Smojver
2007-06-05 23:47:24 UTC
Permalink
Post by Bojan Smojver
testlfs : Line 265: Large Files not supported
Or is this just a misleading message saying "these things are enabled by
default on this platform"?
--
Bojan
Davi Arnaut
2007-06-06 01:44:15 UTC
Permalink
Post by Bojan Smojver
Post by Bojan Smojver
testlfs : Line 265: Large Files not supported
Or is this just a misleading message saying "these things are enabled by
default on this platform"?
Good question. LFS doesn't exist for 64 bit platforms, but because it
supports large files out of the box. This leads to another question,
should APR_HAS_LARGE_FILES be defined on 64-bit systems? It seems
reasonably safe to do so.

How about the following patch?

Index: configure.in
===================================================================
--- configure.in (revision 544571)
+++ configure.in (working copy)
@@ -454,7 +454,7 @@
struct stat64 st;
off64_t off = 4242;

- if (sizeof(off64_t) != 8 || sizeof(off_t) != 4)
+ if (sizeof(off64_t) != 8)
exit(1);
if ((fd = open("conftest.lfs", O_LARGEFILE|O_CREAT|O_WRONLY)) < 0)
exit(2);
William A. Rowe, Jr.
2007-06-06 05:59:49 UTC
Permalink
Post by Davi Arnaut
Post by Bojan Smojver
Post by Bojan Smojver
testlfs : Line 265: Large Files not supported
Or is this just a misleading message saying "these things are enabled by
default on this platform"?
Good question. LFS doesn't exist for 64 bit platforms, but because it
supports large files out of the box. This leads to another question,
should APR_HAS_LARGE_FILES be defined on 64-bit systems? It seems
reasonably safe to do so.
I've always understood HAS_LARGE_FILES to mean that offsets don't fit
into a size_t alignment, they are larger offsets than are otherwise
represented in memory. The thought that apr_off_t > off_t might also
fit that bill.

But no, we should probably figure out how to report this case more
intellegently in testlfs so people don't panic. LARGE_FILES, imho,
should not be set where special handling of the file offsets didn't
happen.
Davi Arnaut
2007-06-06 15:16:00 UTC
Permalink
Post by William A. Rowe, Jr.
Post by Davi Arnaut
Post by Bojan Smojver
Post by Bojan Smojver
testlfs : Line 265: Large Files not supported
Or is this just a misleading message saying "these things are enabled by
default on this platform"?
Good question. LFS doesn't exist for 64 bit platforms, but because it
supports large files out of the box. This leads to another question,
should APR_HAS_LARGE_FILES be defined on 64-bit systems? It seems
reasonably safe to do so.
I've always understood HAS_LARGE_FILES to mean that offsets don't fit
into a size_t alignment, they are larger offsets than are otherwise
represented in memory. The thought that apr_off_t > off_t might also
fit that bill.
As a user of the library, i would thought that with HAS_LARGE_FILES
apr_off_t is guaranteed to be 64 bits long. I wouldn't care about off_t,
since that's not portable.
Post by William A. Rowe, Jr.
But no, we should probably figure out how to report this case more
intellegently in testlfs so people don't panic. LARGE_FILES, imho,
should not be set where special handling of the file offsets didn't
happen.
I think that APR_HAS_LARGE_FILES should be defined whenever we have a 64
bits long apr_off_t, because that's probably what the user want to know
-- if the platform supports large files, which is true for 64 bit
systems. On 32-bits with LFS we should define an internal macro for
special handling of the file offsets. For example, testlfs.c is perfect
fine and should run on 64 bits platforms.

Although not a urgent issue, we should clarify and document better the
APR_HAS_LARGE_FILES meaning.

--
Davi Arnaut
William A. Rowe, Jr.
2007-06-06 21:31:44 UTC
Permalink
Post by Davi Arnaut
Post by William A. Rowe, Jr.
But no, we should probably figure out how to report this case more
intellegently in testlfs so people don't panic. LARGE_FILES, imho,
should not be set where special handling of the file offsets didn't
happen.
I think that APR_HAS_LARGE_FILES should be defined whenever we have a 64
bits long apr_off_t, because that's probably what the user want to know
-- if the platform supports large files, which is true for 64 bit
systems.
What is large? If on a future platform, if off_t (which -is- largely
portable, like ssize_t, just came a little after size_t) is 128 bits and
size_t is 64 bits, that's going to require exception code again.

You are reading APR_HAS_LARGE_FILES as APR_OFF_T_IS_64BIT, but this really
is not true. The flag LARGE_FILE to the apr_file_open tells the system
that you want to open the classic apr_file_t (in apr 0.9) in a mode where
it will handle offsets > size_t bytes wide.

LARGE_FILES tells us that a generic int/void* union will not hold the
offset into a file, and this isn't true of most 64 bit builds.
Post by Davi Arnaut
On 32-bits with LFS we should define an internal macro for
special handling of the file offsets.
For example, testlfs.c is perfect
fine and should run on 64 bits platforms.
This is trues
Post by Davi Arnaut
Although not a urgent issue, we should clarify and document better the
APR_HAS_LARGE_FILES meaning.
+1, after we figure out what that is:0
Gringo Croco
2007-06-06 00:09:54 UTC
Permalink
Disclaimer: I haven't checked to see if this is the right behaviour, I
have an exam tomorow :(

Ubuntu 7.04 32 bit
testsockets : \Segmentation fault (core dumped)

I've tested it twice, with a clean checkout of trunk both times; same behaviour.
All tests before this one worked fine.

--
Lucian Adrian Grijincu
Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
Lucian Adrian Grijincu
2007-06-06 08:40:41 UTC
Permalink
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)

I've done two tests. One in which I ran buildconf myself and one without.
For each test I then ran:
./configure
make
make test

Both failed with:
testsockets : \/bin/bash: line 1: 10039 Segmentation fault
(core dumped) ./$prog

the line possition it reports differs from run to run.

Same system: Ubuntu 7.04, 32bit.

Also:
Still haven't checked if this is to be expected running ./test/testall gives:
testatomic : SUCCESS
testdir : SUCCESS
testdso : FAILED 8 of 9
testdup : SUCCESS
testenv : SUCCESS
testfile : SUCCESS
testfilecopy : FAILED 2 of 4
testfileinfo : SUCCESS
testflock : FAILED 2 of 3
testfmt : SUCCESS
testfnmatch : FAILED 2 of 2
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testlfs : SUCCESS
testmmap : |Segmentation fault (core dumped)

Even though they pass when run from make check.
note trunk isn't 1.2.9 - it's actually 1.3.0 with some additional
socket features, so this is quite possibly not a problem with the
new tarball. would you mind also trying branches/1.2.x or the
tarball i created?
Post by Gringo Croco
Disclaimer: I haven't checked to see if this is the right behaviour, I
have an exam tomorow :(
Ubuntu 7.04 32 bit
testsockets : \Segmentation fault (core dumped)
I've tested it twice, with a clean checkout of trunk both times; same
behaviour.
All tests before this one worked fine.
--
Lucian Adrian Grijincu
Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
Lucian Adrian Grijincu
2007-06-06 11:39:53 UTC
Permalink
the cause: segmentation fault at:
rv = apr_socket_bind(sock, to);
from static void sendto_receivefrom(abts_case *tc, void *data)
from testsockets.c
the second parameter given is NULL:
apr_socket_bind (sock=0x80d3c78, sa=0x0) at network_io/unix/sockets.c:154

the NULL value comes from
rv = apr_sockaddr_info_get(&to, addr, APR_UNSPEC, 7772, 0, p);
Which was supposed to initialize it, but failed to.

digging deeper we get into network_io/unix/soccaddr.c, where there's a
this call
error = getaddrinfo(hostname, servname, &hints, &ai_list);
This returns -9 which gai_strerror says it means "Address family for
hostname not supported".
getaddrinfo's input params are:
hostname ="::1"
servname = 0x0
hints = {ai_flags = AI_ADDRCONFIG, ai_family = 0,
ai_socktype = 1, ai_protocol = 0, ai_addrlen = 0, ai_addr = 0x0,
ai_canonname = 0x0, ai_next = 0x0}

Will dig deeper, but if somebody has some knowledge why this would
fail, jump in :)

--
Lucian Adrian Grijincu
Post by Lucian Adrian Grijincu
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
./configure
make
make test
testsockets : \/bin/bash: line 1: 10039 Segmentation fault
(core dumped) ./$prog
the line possition it reports differs from run to run.
Same system: Ubuntu 7.04, 32bit.
testatomic : SUCCESS
testdir : SUCCESS
testdso : FAILED 8 of 9
testdup : SUCCESS
testenv : SUCCESS
testfile : SUCCESS
testfilecopy : FAILED 2 of 4
testfileinfo : SUCCESS
testflock : FAILED 2 of 3
testfmt : SUCCESS
testfnmatch : FAILED 2 of 2
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testlfs : SUCCESS
testmmap : |Segmentation fault (core dumped)
Even though they pass when run from make check.
note trunk isn't 1.2.9 - it's actually 1.3.0 with some additional
socket features, so this is quite possibly not a problem with the
new tarball. would you mind also trying branches/1.2.x or the
tarball i created?
Post by Gringo Croco
Disclaimer: I haven't checked to see if this is the right behaviour, I
have an exam tomorow :(
Ubuntu 7.04 32 bit
testsockets : \Segmentation fault (core dumped)
I've tested it twice, with a clean checkout of trunk both times; same
behaviour.
All tests before this one worked fine.
--
Lucian Adrian Grijincu
Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
Davi Arnaut
2007-06-06 16:39:52 UTC
Permalink
Post by Lucian Adrian Grijincu
rv = apr_socket_bind(sock, to);
from static void sendto_receivefrom(abts_case *tc, void *data)
from testsockets.c
apr_socket_bind (sock=0x80d3c78, sa=0x0) at network_io/unix/sockets.c:154
the NULL value comes from
rv = apr_sockaddr_info_get(&to, addr, APR_UNSPEC, 7772, 0, p);
Which was supposed to initialize it, but failed to.
digging deeper we get into network_io/unix/soccaddr.c, where there's a
this call
error = getaddrinfo(hostname, servname, &hints, &ai_list);
This returns -9 which gai_strerror says it means "Address family for
hostname not supported".
hostname ="::1"
servname = 0x0
hints = {ai_flags = AI_ADDRCONFIG, ai_family = 0,
ai_socktype = 1, ai_protocol = 0, ai_addrlen = 0, ai_addr = 0x0,
ai_canonname = 0x0, ai_next = 0x0}
Hum, it seems the call_resolver (or the test) code is wrong because for
APR_UNSPEC it adds AI_ADDRCONFIG to the flags, which excludes loopback
addresses.

According to the getaddrinfo documentation, the loopback address is not
considered a valid configured address.

--
Davi Arnaut
Colm MacCarthaigh
2007-06-06 23:21:44 UTC
Permalink
Post by Davi Arnaut
Post by Lucian Adrian Grijincu
digging deeper we get into network_io/unix/soccaddr.c, where there's a
this call
error = getaddrinfo(hostname, servname, &hints, &ai_list);
This returns -9 which gai_strerror says it means "Address family for
hostname not supported".
hostname ="::1"
servname = 0x0
hints = {ai_flags = AI_ADDRCONFIG, ai_family = 0,
ai_socktype = 1, ai_protocol = 0, ai_addrlen = 0, ai_addr = 0x0,
ai_canonname = 0x0, ai_next = 0x0}
Hum, it seems the call_resolver (or the test) code is wrong because for
APR_UNSPEC it adds AI_ADDRCONFIG to the flags
Now looking at the actual bug in the test ...

Seems like it's acceptable to fall back to 127.0.0.1 in that situation
though, as an easy fix. So if we use the _info_get() call as the test
instead of "can we create an IPv6 socket", that's enough.

But if we do use IPv6, there are other problems, later on in the
code (at least on trunk) ...

164 apr_sockaddr_info_get(&from, "127.1.2.3", APR_INET, 4242, 0, p);
165
166 len = 80;
167 rv = apr_socket_recvfrom(from, sock, 0, recvbuf, &len);

if sock is an IPv6 socket, that's not going to be fun!

Looking at the test, I think we should have two tests, one for IPv6
and one for IPv4. Run them both, allow the IPv6 one to fail (if the
module is not loaded or whatever). Does that seem acceptable to
people ? I volunteer to help make the changes anyway, the current
state is a mess :-)
--
Colm MacCárthaigh Public Key: colm+***@stdlib.net
William A. Rowe, Jr.
2007-06-06 23:36:52 UTC
Permalink
Post by Colm MacCarthaigh
Looking at the test, I think we should have two tests, one for IPv6
and one for IPv4. Run them both, allow the IPv6 one to fail (if the
module is not loaded or whatever). Does that seem acceptable to
people ? I volunteer to help make the changes anyway, the current
state is a mess :-)
+1 - that sounds like a great solution. Do you want me to hold off on
the 1.2.10 tag for a day or two to slip this in, now that we know what
the case is? Or is there a simpler short term solution to let us get
together a solid 1.2.10 for httpd-2.2.5 and others who need a release
sooner rather than later?

Bill
Colm MacCarthaigh
2007-06-06 23:44:42 UTC
Permalink
Post by William A. Rowe, Jr.
+1 - that sounds like a great solution. Do you want me to hold off on
the 1.2.10 tag for a day or two to slip this in, now that we know what
the case is?
Nah, it's been like that for ages :-)
--
Colm MacCárthaigh Public Key: colm+***@stdlib.net
Davi Arnaut
2007-06-07 03:15:57 UTC
Permalink
Post by Colm MacCarthaigh
Post by William A. Rowe, Jr.
+1 - that sounds like a great solution. Do you want me to hold off on
the 1.2.10 tag for a day or two to slip this in, now that we know what
the case is?
Nah, it's been like that for ages :-)
In any case, I like to have a working make test. The patch attached has been
tested on Ubuntu and Fedora.

--
Davi Arnaut
Lucian Adrian Grijincu
2007-06-06 15:06:44 UTC
Permalink
I've gotten it down to this:
int getaddrinfo(const char *node, const char *service,
const struct addrinfo *hints,
struct addrinfo **res);

getaddrinfo hates "::1" as a node parameter.
I've attached a tester for getaddrinfo (based on Ulrich Drepper's
http://people.redhat.com/drepper/userapi-ipv6.html )

$> netstat -a -t -p
tcp 0 0 *:www *:*
LISTEN -
tcp6 0 0 *:ssh *:*
LISTEN -

$>./test ::1 ssh
./test: getaddrinfo: Address family for hostname not supported

$> telnet ::1 ssh
Trying ::1...
Connected to ::1.
Escape character is '^]'.
SSH-2.0-OpenSSH_4.3p2 Debian-8ubuntu1



$>./test ::1 www
./test: getaddrinfo: Address family for hostname not supported

$>telnet ::1 www
Trying ::1...
telnet: Unable to connect to remote host: Connection refused

both
$>./test 127.0.0.1 www
and
$>./test 127.0.0.1 ssh

succeed (aka I can talk to the www or ssh daemons running on my system).

If anyone's got a clue, please say so ... I'm kind of in the mists now :)
If not, when I get the time, I'll look into telnet's implementation to
see what they do to accept "::1"


--
Lucian Adrian Grijincu
Post by Lucian Adrian Grijincu
rv = apr_socket_bind(sock, to);
from static void sendto_receivefrom(abts_case *tc, void *data)
from testsockets.c
apr_socket_bind (sock=0x80d3c78, sa=0x0) at network_io/unix/sockets.c:154
the NULL value comes from
rv = apr_sockaddr_info_get(&to, addr, APR_UNSPEC, 7772, 0, p);
Which was supposed to initialize it, but failed to.
digging deeper we get into network_io/unix/soccaddr.c, where there's a
this call
error = getaddrinfo(hostname, servname, &hints, &ai_list);
This returns -9 which gai_strerror says it means "Address family for
hostname not supported".
hostname ="::1"
servname = 0x0
hints = {ai_flags = AI_ADDRCONFIG, ai_family = 0,
ai_socktype = 1, ai_protocol = 0, ai_addrlen = 0, ai_addr = 0x0,
ai_canonname = 0x0, ai_next = 0x0}
Will dig deeper, but if somebody has some knowledge why this would
fail, jump in :)
--
Lucian Adrian Grijincu
Post by Lucian Adrian Grijincu
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
./configure
make
make test
testsockets : \/bin/bash: line 1: 10039 Segmentation fault
(core dumped) ./$prog
the line possition it reports differs from run to run.
Same system: Ubuntu 7.04, 32bit.
testatomic : SUCCESS
testdir : SUCCESS
testdso : FAILED 8 of 9
testdup : SUCCESS
testenv : SUCCESS
testfile : SUCCESS
testfilecopy : FAILED 2 of 4
testfileinfo : SUCCESS
testflock : FAILED 2 of 3
testfmt : SUCCESS
testfnmatch : FAILED 2 of 2
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testlfs : SUCCESS
testmmap : |Segmentation fault (core dumped)
Even though they pass when run from make check.
note trunk isn't 1.2.9 - it's actually 1.3.0 with some additional
socket features, so this is quite possibly not a problem with the
new tarball. would you mind also trying branches/1.2.x or the
tarball i created?
Post by Gringo Croco
Disclaimer: I haven't checked to see if this is the right behaviour, I
have an exam tomorow :(
Ubuntu 7.04 32 bit
testsockets : \Segmentation fault (core dumped)
I've tested it twice, with a clean checkout of trunk both times; same
behaviour.
All tests before this one worked fine.
--
Lucian Adrian Grijincu
Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
Davi Arnaut
2007-06-06 18:05:17 UTC
Permalink
Post by Lucian Adrian Grijincu
int getaddrinfo(const char *node, const char *service,
const struct addrinfo *hints,
struct addrinfo **res);
getaddrinfo hates "::1" as a node parameter.
I've attached a tester for getaddrinfo (based on Ulrich Drepper's
http://people.redhat.com/drepper/userapi-ipv6.html )
<snip>
Post by Lucian Adrian Grijincu
If anyone's got a clue, please say so ... I'm kind of in the mists now :)
If not, when I get the time, I'll look into telnet's implementation to
see what they do to accept "::1"
See my email about it, message id <***@haxent.com.br>

It boils down to a combination of ai_flags = AI_ADDRCONFIG and "::1"
(loopback address). The test is wrong, it should expect a failure (with
the current network_io code adding the AI_ADDRCONFIG flag).

--
Davi Arnaut
William A. Rowe, Jr.
2007-06-06 21:33:53 UTC
Permalink
Post by Davi Arnaut
It boils down to a combination of ai_flags = AI_ADDRCONFIG and "::1"
(loopback address). The test is wrong, it should expect a failure (with
the current network_io code adding the AI_ADDRCONFIG flag).
Thanks for the research, which solution do we want?

[ ] undo the AI_ADDRCONFIG flag which interferes with loopback?
[ ] document that loopback isn't a valid address?

I'm guessing the former.

Bill
Colm MacCarthaigh
2007-06-06 22:50:24 UTC
Permalink
Post by Davi Arnaut
It boils down to a combination of ai_flags = AI_ADDRCONFIG and "::1"
(loopback address). The test is wrong, it should expect a failure (with
the current network_io code adding the AI_ADDRCONFIG flag).
O.k., I think you're mis-interpretting things here. The purpose of the
AI_ADDRCONFIG flag is to determine if getaddrinfo should bother to
return IPv6 addresses or not, it's a basic "Do I actually have IPv6
connectivity?" test.

It works by determining if your system has a useable non-localhost IPv6
address set, so if I have 2001:770:18::2 on an interface the answer is
"yes". "::1" is not treated at all differently by getaddrinfo as a
parameter. Where ::1 comes in is that if it's the only IPv6 address
configured on your system, the answer to the AI_ADDRCONFIG test is "no".
Having ::1 does not mean you have useable IPv6 connectivity generally,
and so the aim is that the call does not return it.

In other words, if I ran this test on my system, which does have
a public IPv6 address, it would work just fine. "::1" as a parameter
is not special.

Does that make sence? I can explain more verbosely too.
--
Colm MacCárthaigh Public Key: colm+***@stdlib.net
Davi Arnaut
2007-06-06 23:32:12 UTC
Permalink
Post by Colm MacCarthaigh
Post by Davi Arnaut
It boils down to a combination of ai_flags = AI_ADDRCONFIG and "::1"
(loopback address). The test is wrong, it should expect a failure (with
the current network_io code adding the AI_ADDRCONFIG flag).
O.k., I think you're mis-interpretting things here. The purpose of the
AI_ADDRCONFIG flag is to determine if getaddrinfo should bother to
return IPv6 addresses or not, it's a basic "Do I actually have IPv6
connectivity?" test.
Yes, i'm pretty confused by AI_ADDRCONFIG.
Post by Colm MacCarthaigh
It works by determining if your system has a useable non-localhost IPv6
address set, so if I have 2001:770:18::2 on an interface the answer is
"yes". "::1" is not treated at all differently by getaddrinfo as a
parameter. Where ::1 comes in is that if it's the only IPv6 address
configured on your system, the answer to the AI_ADDRCONFIG test is "no".
Having ::1 does not mean you have useable IPv6 connectivity generally,
and so the aim is that the call does not return it.
In other words, if I ran this test on my system, which does have
a public IPv6 address, it would work just fine. "::1" as a parameter
is not special.
Does that make sence? I can explain more verbosely too.
Sorry, but i still don't quite understand. For example:

/Users/davi/gai $ ./gai -na ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC,
.hints=0|AI_ADDRCONFIG|AI_NUMERICHOST}) = 0:
family=30, proto= 6 inet6: addr=::1, port=0, flowinfo=0

How come this succeeded? The system doesn't have any public ipv6,
the only "configured" ipv6 address is ::1.

/Users/davi/gai $ ./gai -na
getaddrinfo(NULL, NULL, {.family=AF_UNSPEC,
.hints=0|AI_ADDRCONFIG|AI_NUMERICHOST}) = -1:
error: nodename nor servname provided, or not known

--
Davi Arnaut
Colm MacCarthaigh
2007-06-06 23:40:14 UTC
Permalink
Post by Davi Arnaut
/Users/davi/gai $ ./gai -na ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC,
family=30, proto= 6 inet6: addr=::1, port=0, flowinfo=0
How come this succeeded? The system doesn't have any public ipv6,
the only "configured" ipv6 address is ::1.
AI_NUMERICHOST trumps AI_ADDRCONFIG on some platforms because people
infer that if you supply it you are being more specific in your request.
The technical reason is because the decision to make an AAAA query or
not is buried in their resolver code (*cough*, this may or may not be my
fault) , and that code never gets triggered when you use AI_NUMERICHOST.

It's not strictly in the letter of rfc3493 though, it's a resolver bug.
Post by Davi Arnaut
/Users/davi/gai $ ./gai -na
getaddrinfo(NULL, NULL, {.family=AF_UNSPEC,
error: nodename nor servname provided, or not known
Why wouldn't that fail?
--
Colm MacCárthaigh Public Key: colm+***@stdlib.net
Davi Arnaut
2007-06-06 23:49:06 UTC
Permalink
Post by Colm MacCarthaigh
Post by Davi Arnaut
/Users/davi/gai $ ./gai -na ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC,
family=30, proto= 6 inet6: addr=::1, port=0, flowinfo=0
How come this succeeded? The system doesn't have any public ipv6,
the only "configured" ipv6 address is ::1.
AI_NUMERICHOST trumps AI_ADDRCONFIG on some platforms because people
infer that if you supply it you are being more specific in your request.
The technical reason is because the decision to make an AAAA query or
not is buried in their resolver code (*cough*, this may or may not be my
fault) , and that code never gets triggered when you use AI_NUMERICHOST.
It's not strictly in the letter of rfc3493 though, it's a resolver bug.
Ok, ack.
Post by Colm MacCarthaigh
Post by Davi Arnaut
/Users/davi/gai $ ./gai -na
getaddrinfo(NULL, NULL, {.family=AF_UNSPEC,
error: nodename nor servname provided, or not known
Why wouldn't that fail?
Sorry, it should have been:

getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG}) = 0:
family=30, proto= 6 inet6: addr=::1, port=0, flowinfo=0

Last question (sorry for wasting your time), why this one succeeded?

--
Davi Arnaut
Colm MacCarthaigh
2007-06-06 23:56:26 UTC
Permalink
Post by Davi Arnaut
Post by Colm MacCarthaigh
Why wouldn't that fail?
family=30, proto= 6 inet6: addr=::1, port=0, flowinfo=0
Last question (sorry for wasting your time), why this one succeeded?
If you don't have a public IPv6 address, per the RFC - it should fail,
it's a resolver bug.

In the real world, it could be NSCD, or another libc cache :-)
--
Colm MacCárthaigh Public Key: colm+***@stdlib.net
Joe Orton
2007-06-06 18:56:10 UTC
Permalink
Post by Lucian Adrian Grijincu
$>./test ::1 ssh
./test: getaddrinfo: Address family for hostname not supported
$> telnet ::1 ssh
Trying ::1...
Connected to ::1.
That makes little sense. I presume you do in fact have the "ipv6"
module loaded (lsmod | grep ipv6)? What version of glibc is this? Does
it make any difference if you set ai_flags to 0 in your test program?

joe
Davi Arnaut
2007-06-06 19:10:27 UTC
Permalink
Post by Joe Orton
Post by Lucian Adrian Grijincu
$>./test ::1 ssh
./test: getaddrinfo: Address family for hostname not supported
$> telnet ::1 ssh
Trying ::1...
Connected to ::1.
That makes little sense. I presume you do in fact have the "ipv6"
module loaded (lsmod | grep ipv6)? What version of glibc is this? Does
it make any difference if you set ai_flags to 0 in your test program?
In case anyone wanna try.. test attached.

--
Davi Arnaut
Lucian Adrian Grijincu
2007-06-06 19:57:00 UTC
Permalink
Post by Davi Arnaut
Post by Joe Orton
Post by Lucian Adrian Grijincu
$>./test ::1 ssh
./test: getaddrinfo: Address family for hostname not supported
$> telnet ::1 ssh
Trying ::1...
Connected to ::1.
That makes little sense. I presume you do in fact have the "ipv6"
module loaded (lsmod | grep ipv6)? What version of glibc is this? Does
it make any difference if you set ai_flags to 0 in your test program?
***@h:~$ lsmod | grep ipv6
ipv6 268960 12

I guess 2.5 :)
Ubuntu reports it as 2.5-0ubuntu14

***@h:~$ ls -al /lib/libc.so.6
lrwxrwxrwx 1 root root 11 2007-05-18 01:12 /lib/libc.so.6 -> libc-2.5.so

I think that telnet could see that "::1" is the IPv6 loopback string
and replace it with "127.0.0.1" if it wanted. Haven' looked at the
code, just why this behaviour may be possible.
Post by Davi Arnaut
In case anyone wanna try.. test attached.
This is the output:
getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.

--
Lucian Adrian Grijincu
Joe Orton
2007-06-06 21:18:41 UTC
Permalink
Post by Lucian Adrian Grijincu
getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.
Just so I can understand the precise nuances of this, can you post the
output of:

wget http://people.apache.org/~jorton/gai.c
make gai
./gai ::1
./gai ::1 null inet6
./gai -a ::1
./gai -a ::1 null inet6

But yes, testsockets.c will need some tweaking to cope with this
getaddrinfo implementation. I think it's caused by an Ubuntu patch, if
I read https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828
correctly. It might break some applications in fun ways too, but
there's not much APR can do about that.

joe
Davi Arnaut
2007-06-06 22:06:48 UTC
Permalink
Post by Joe Orton
Post by Lucian Adrian Grijincu
getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.
Just so I can understand the precise nuances of this, can you post the
wget http://people.apache.org/~jorton/gai.c
make gai
./gai ::1
./gai ::1 null inet6
./gai -a ::1
./gai -a ::1 null inet6
Ubuntu 7.04 (no ipv6 addresses -- other then loopback -- configured):

***@karmic:~/gai$ make gai
cc gai.c -o gai
***@karmic:~/gai$ ./gai ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0}) = 0:
family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
***@karmic:~/gai$ ./gai ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0}) = 0:
family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
***@karmic:~/gai$ ./gai -a ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG}) = -1:
error: Address family for hostname not supported
***@karmic:~/gai$ ./gai -a ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0|AI_ADDRCONFIG}) = -1:
error: Name or service not known
Post by Joe Orton
But yes, testsockets.c will need some tweaking to cope with this
getaddrinfo implementation. I think it's caused by an Ubuntu patch, if
I read https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828
correctly. It might break some applications in fun ways too, but
there's not much APR can do about that.
Interesting bits of documentation:

win32:

"If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
returned only if an IPv4 address is configured on the local system, and
IPv6 addresses shall be returned only if an IPv6 address is configured
on the local system. The IPv4 or IPv6 loopback address is not considered
a valid global address."

RFC 3943:

"If the AI_ADDRCONFIG flag is specified, IPv4 addresses shall be
returned only if an IPv4 address is configured on the local system,
and IPv6 addresses shall be returned only if an IPv6 address is
configured on the local system. The loopback address is not
considered for this case as valid as a configured address."

Solaris:

"If the AI_ADDRCONFIG flag is specified, IPv4 addresses are returned
only if an IPv4 address is configured on the local system, and IPv6
addresses are returned only if an IPv6 address is configured on the
local system. For this case, the loopback address is not considered to
be as valid as a configured address. "

--
Davi Aranut
Davi Arnaut
2007-06-06 22:20:44 UTC
Permalink
Post by Joe Orton
Post by Lucian Adrian Grijincu
getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.
Just so I can understand the precise nuances of this, can you post the
wget http://people.apache.org/~jorton/gai.c
make gai
./gai ::1
./gai ::1 null inet6
./gai -a ::1
./gai -a ::1 null inet6
Solaris:

[***@sunfire280 x]$ ./gai ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0}) = 0:
family=26, proto= 0 inet6: addr=::1, port=0, flowinfo=0

[***@sunfire280 x]$ ./gai ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0}) = 0:
family=26, proto= 0 inet6: addr=::1, port=0, flowinfo=0

[***@sunfire280 x]$ ./gai -a ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG}) = 0:
family=26, proto= 0 inet6: addr=::1, port=0, flowinfo=0

[***@sunfire280 x]$ ./gai -a ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0|AI_ADDRCONFIG}) = 0:
Davi Arnaut
2007-06-06 23:15:49 UTC
Permalink
Post by Davi Arnaut
Post by Joe Orton
Post by Lucian Adrian Grijincu
getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.
Just so I can understand the precise nuances of this, can you post the
wget http://people.apache.org/~jorton/gai.c
make gai
./gai ::1
./gai ::1 null inet6
./gai -a ::1
./gai -a ::1 null inet6
cc gai.c -o gai
family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|
error: Address family for hostname not supported
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0|
error: Name or service not known
Same machine, now with -n:

***@karmic:~/gai$ ./gai -n ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|
AI_NUMERICHOST}) = 0:
family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
***@karmic:~/gai$ ./gai -n ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0|AI_NUMERICHOST})
= 0:
family=10, proto= 6 inet6: addr=::1, port=0, flowinfo=0
***@karmic:~/gai$ ./gai -na ::1
getaddrinfo("::1", NULL, {.family=AF_UNSPEC, .hints=0|AI_ADDRCONFIG|
AI_NUMERICHOST}) = -1:
error: Address family for hostname not supported
***@karmic:~/gai$ ./gai -na ::1 null inet6
getaddrinfo("::1", NULL, {.family=AF_INET6, .hints=0|AI_ADDRCONFIG|
AI_NUMERICHOST}) = -1:
error: Name or service not known
Joe Orton
2007-06-06 23:40:37 UTC
Permalink
Thanks. Was the last line omitted from the results for Solaris which
you posted, or was it really a NULL result list?

I don't think this provides any reason to change the APR resolver code.
Ubuntu systems may be a bit schizophrenic about whether ::1 exists,
depending on whether your app uses AI_ADDRCONFIG or not, but it seems to
be by design.

The testsockets.c problem is certainly not new, I don't see why it
should block a release. That code has always been pretty fragile.

joe
Davi Arnaut
2007-06-06 23:52:02 UTC
Permalink
Post by Joe Orton
Thanks. Was the last line omitted from the results for Solaris which
you posted, or was it really a NULL result list?
Probably omitted -- cut-and-pasted from chat log.
Post by Joe Orton
I don't think this provides any reason to change the APR resolver code.
Ubuntu systems may be a bit schizophrenic about whether ::1 exists,
depending on whether your app uses AI_ADDRCONFIG or not, but it seems to
be by design.
The testsockets.c problem is certainly not new, I don't see why it
should block a release. That code has always been pretty fragile.
+1
Lucian Adrian Grijincu
2007-06-07 00:18:38 UTC
Permalink
Post by Joe Orton
Thanks. Was the last line omitted from the results for Solaris which
you posted, or was it really a NULL result list?
I don't think this provides any reason to change the APR resolver code.
Ubuntu systems may be a bit schizophrenic about whether ::1 exists,
depending on whether your app uses AI_ADDRCONFIG or not, but it seems to
be by design.
The code that sets AI_ADDRCONFIG checks the error message returned by
getaddrinfo. If family was APR_UNSPEC and the error was EAI_BADFLAGS
(which basically means failed because of a bad flag:) ) it retries
with flags set to null.

I think the Ubuntu 7.04 people wrongfully return EAI_ADDRFAMILY, when
EAI_BADFLAGS would be just fine, because changing the flag makes the
call succeed and there is a ::1 address in the specified family.

A solution that *works* is to check for both error codes and if either
is returned and were in APR_UNSPEC mode, retry without EAI_ADDRFAMILY.
Post by Joe Orton
The testsockets.c problem is certainly not new, I don't see why it
should block a release. That code has always been pretty fragile.
joe
--
Lucian Adrian Grijincu
Colm MacCarthaigh
2007-06-06 23:09:04 UTC
Permalink
Post by Joe Orton
Post by Lucian Adrian Grijincu
getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.
Just so I can understand the precise nuances of this, can you post the
wget http://people.apache.org/~jorton/gai.c
This won't help this time :/ The key thing is that AI_ADDRCONFIG
makes getaddrinfo behave differently based on what addresses are
configured on your systems interfaces, not based on any other
parameters to getaddrinfo.
--
Colm MacCárthaigh Public Key: colm+***@stdlib.net
Tollef Fog Heen
2007-06-07 06:41:24 UTC
Permalink
* Joe Orton

| But yes, testsockets.c will need some tweaking to cope with this
| getaddrinfo implementation. I think it's caused by an Ubuntu patch, if
| I read https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828
| correctly. It might break some applications in fun ways too, but
| there's not much APR can do about that.

FWIW, I have yet to see any bug reports about anything breaking with
this, except testsockets.c.

What the glibc patch does is it only returns IPv6 addresses if they
are explicitly requested by the application or you have an IPv6
address with a scope of < link (that is, if you have site or global
scope address).

The reason for the patch is lots of cheap DSL routers seem to just not
respond to AAAA or A6 queries, so applications would try to resolve a
name, glibc would send out an AAAA query, wait for it to time out,
then send out an A request instead of just getting a NXDOMAIN or
similar back immediately. So, it's a hack for brokenness in lots of
software which is not Ubuntu's, but it makes the user experience much
better without breaking IPv6 for those who actually use it.

Whether it should treat numeric addresses specifically is something I
had not considered; maybe it should. I would be happy to receive
feedback on this. On the other hand, I would suspect the number of
people keying in IPv6 addresses into their applications and not having
a site or global IPv6 address to be fairly small so real-world
breakage should be limited.
--
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are
Lucian Adrian Grijincu
2007-06-06 21:24:07 UTC
Permalink
Post by Lucian Adrian Grijincu
Post by Davi Arnaut
Post by Joe Orton
Post by Lucian Adrian Grijincu
$>./test ::1 ssh
./test: getaddrinfo: Address family for hostname not supported
$> telnet ::1 ssh
Trying ::1...
Connected to ::1.
That makes little sense. I presume you do in fact have the "ipv6"
module loaded (lsmod | grep ipv6)? What version of glibc is this? Does
it make any difference if you set ai_flags to 0 in your test program?
ipv6 268960 12
I guess 2.5 :)
Ubuntu reports it as 2.5-0ubuntu14
lrwxrwxrwx 1 root root 11 2007-05-18 01:12 /lib/libc.so.6 -> libc-2.5.so
I think that telnet could see that "::1" is the IPv6 loopback string
and replace it with "127.0.0.1" if it wanted. Haven' looked at the
code, just why this behaviour may be possible.
Post by Davi Arnaut
In case anyone wanna try.. test attached.
getaddrinfo AF_UNSPEC/SOCK_STREAM/AI_ADDRCONFIG failed
so, yes: hints.ai_flags = AI_ADDRCONFIG; makes getaddrinfo fail.
commenting out AI_ADDRCONFIG in the malfunctioning code makes it pass all tests.

#ifdef HAVE_GAI_ADDRCONFIG
if (family == APR_UNSPEC) {
/* By default, only look up addresses using address types for
* which a local interface is configured, i.e. no IPv6 if no
* IPv6 interfaces configured. */

//hints.ai_flags = AI_ADDRCONFIG;
}
#endif

I hear that there are real performance reasons to maintain
AI_ADDRCONFIG for AF_UNSPEC:
http://www.ops.ietf.org/lists/v6ops/v6ops.2003/msg01377.html

I first though we could do a strcmp to check for "127.0.0.1" or "::1",
but it's not going to work, because users may have altered the hosts
file to set a specific hostname to loopback and this code should be
able to get things like "localhost" as a valid parameter.

I see three getaways:
1. kill AI_ADDRCONFIG for APR_UNSPEC
2. document "::1" and any other link-local addresses and hostnames as
invalid if APR_UNSPEC is used.
3. retry without AI_ADDRCONFIG if first try fails

1. BAD: this is the only place where AI_ADDRCONFIG is used and not
using it would mean a performance regression for applications that do
not care about loopback.
2. UGLY: APR should work arround platform specific issues and present
a simple interface. Having the user check for link-localness
beforehand is ... ugly. :)
3. GOOD: We already retry for some other errors and retrying would
only harm performance-wise only in case of a:
a) link-local address or hostname. This should be resolved locally,
which means the drawback is little
b) failing external lookup. This can mean we'll take longer to say:
"I can't find the hostname you specified", or (not very probable)
manage to find it at the second try


I've attached a patch against the tarball that does what's needed for 3.

Rebuilt from scratch + patch:
finally, all test pass now :)


--
Lucian Adrian Grijincu
William A. Rowe, Jr.
2007-06-06 21:45:43 UTC
Permalink
Post by Lucian Adrian Grijincu
I hear that there are real performance reasons to maintain
http://www.ops.ietf.org/lists/v6ops/v6ops.2003/msg01377.html
I first though we could do a strcmp to check for "127.0.0.1" or "::1",
but it's not going to work, because users may have altered the hosts
file to set a specific hostname to loopback and this code should be
able to get things like "localhost" as a valid parameter.
Correct, that won't work. Although looking for "127." or "::" prefixes
might be a legimate test, however "localhost" won't resolve.

Remember that setting up the loopback IP's .1, .2, .3, .4 all on the
same port might be a reasonable design of a local app and wouldn't pass
if you looked for the full loopback IP.
Post by Lucian Adrian Grijincu
1. kill AI_ADDRCONFIG for APR_UNSPEC
2. document "::1" and any other link-local addresses and hostnames as
invalid if APR_UNSPEC is used.
3. retry without AI_ADDRCONFIG if first try fails
1. BAD: this is the only place where AI_ADDRCONFIG is used and not
using it would mean a performance regression for applications that do
not care about loopback.
2. UGLY: APR should work arround platform specific issues and present
a simple interface. Having the user check for link-localness
beforehand is ... ugly. :)
3. GOOD: We already retry for some other errors and retrying would
a) link-local address or hostname. This should be resolved locally,
which means the drawback is little
"I can't find the hostname you specified", or (not very probable)
manage to find it at the second try
I've attached a patch against the tarball that does what's needed for 3.
finally, all test pass now :)
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10 IMHO
(along with other small fixes that are identified today or tomorrow morning.)

Bill
Ruediger Pluem
2007-06-06 22:03:03 UTC
Permalink
Post by William A. Rowe, Jr.
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10 IMHO
(along with other small fixes that are identified today or tomorrow morning.)
I know, that I am late with this, but how about backporting the patch for PR28205
(http://issues.apache.org/bugzilla/show_bug.cgi?id=28205)?

Additionally to my remarks in #12 I also checked it now on RHAS4 64 bit without
any hasle.

Regards

Rüdiger
William A. Rowe, Jr.
2007-06-06 22:10:27 UTC
Permalink
Post by Ruediger Pluem
Post by William A. Rowe, Jr.
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10 IMHO
(along with other small fixes that are identified today or tomorrow morning.)
I know, that I am late with this, but how about backporting the patch for PR28205
(http://issues.apache.org/bugzilla/show_bug.cgi?id=28205)?
Additionally to my remarks in #12 I also checked it now on RHAS4 64 bit without
any hasle.
IIUC - this patch does NOT add -L/path at all for /usr/lib, /usr/lib64, if the
compiler resolves the -lexpat, correct?

If so, amen! Be my guest to get this committed and get our fingers our of the
compiler's business.
Ruediger Pluem
2007-06-07 07:00:13 UTC
Permalink
Post by William A. Rowe, Jr.
Post by Ruediger Pluem
Post by William A. Rowe, Jr.
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10 IMHO
(along with other small fixes that are identified today or tomorrow morning.)
I know, that I am late with this, but how about backporting the patch for PR28205
(http://issues.apache.org/bugzilla/show_bug.cgi?id=28205)?
Additionally to my remarks in #12 I also checked it now on RHAS4 64 bit without
any hasle.
IIUC - this patch does NOT add -L/path at all for /usr/lib, /usr/lib64, if the
compiler resolves the -lexpat, correct?
Looks like to me. Maybe Joe can confirm.

Regards

Rüdiger
Joe Orton
2007-06-07 09:39:24 UTC
Permalink
Post by Ruediger Pluem
Post by William A. Rowe, Jr.
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10 IMHO
(along with other small fixes that are identified today or tomorrow morning.)
I know, that I am late with this, but how about backporting the patch for PR28205
(http://issues.apache.org/bugzilla/show_bug.cgi?id=28205)?
Additionally to my remarks in #12 I also checked it now on RHAS4 64 bit without
any hasle.
I was hoping to see this get some testing on some more exotic/less
modern systems, to try to flush out any regressions :(

But since more and more systems are hitting this it's probably worth
including in 1.2.x. Thanks for the backport, testing, and persistence -
r545129.

joe
William A. Rowe, Jr.
2007-06-07 14:07:01 UTC
Permalink
Post by Joe Orton
I was hoping to see this get some testing on some more exotic/less
modern systems, to try to flush out any regressions :(
Well the new logic is quite clean. Someday a lcllibpth like variable
that perl builds would be sweet (for searching the unusual/platform
specific locations like /sw/bin, /opt/sfw, /usr/sfw etc). Nothing
wrong with asking users to be specific if it's not in the expected
locations, though.
Post by Joe Orton
But since more and more systems are hitting this it's probably worth
including in 1.2.x. Thanks for the backport, testing, and persistence -
r545129.
Not that we care quite so much anymore, but does 0.9 hit the same issue?
William A. Rowe, Jr.
2007-06-07 00:48:24 UTC
Permalink
can someone please illuminate me what needs to be done to have a
single source file be compiled and linked on all platforms?
http://mail-archives.apache.org/mod_mbox/apr-dev/200612.mbox/browser
It's an implementation of "rm -d -r" based only on APR objects.
Of course, it's too late to extend the 1.2 api, this could be backported
to 0.9 if you desired, and added to trunk of course.

1. drop the file in unix/
2. add a new #SOURCE section in the libapr.dsp and apr.dsp win32 build
files which add that new source (pointing to the unix tree).
3. for other platforms which -exist- (don't add a platform, the build will
default to unix/ where another doesn't exist) add the same-named source
consisting of nothing but an #include "../unix/foo.c" which means we have
only one source to maintain.
4. add to the NW build (ENOCLUE offhand, you might look at a recent commit
or someone else might pipe in).
Davi Arnaut
2007-06-07 00:54:23 UTC
Permalink
can someone please illuminate me what needs to be done to have a
single source file be compiled and linked on all platforms?
http://mail-archives.apache.org/mod_mbox/apr-dev/200705.mbox/%
http://mail-archives.apache.org/mod_mbox/apr-dev/200612.mbox/browser
It's an implementation of "rm -d -r" based only on APR objects.
Clueless question: Would it be better to use ftw() (or nftw(), or fts
()) for traversing?

--
Davi Arnaut
Brad Nicholes
2007-06-07 14:18:04 UTC
Permalink
Post by Lucian Adrian Grijincu
can someone please illuminate me what needs to be done to have a
single source file be compiled and linked on all platforms?
http://mail-archives.apache.org/mod_mbox/apr-dev/200705.mbox/%3c4d45da0507051
http://mail-archives.apache.org/mod_mbox/apr-dev/200612.mbox/browser
It's an implementation of "rm -d -r" based only on APR objects.
Of course, it's too late to extend the 1.2 api, this could be backported
to 0.9 if you desired, and added to trunk of course.
1. drop the file in unix/
2. add a new #SOURCE section in the libapr.dsp and apr.dsp win32 build
files which add that new source (pointing to the unix tree).
3. for other platforms which -exist- (don't add a platform, the build will
default to unix/ where another doesn't exist) add the same-named source
consisting of nothing but an #include "../unix/foo.c" which means we have
only one source to maintain.
4. add to the NW build (ENOCLUE offhand, you might look at a recent commit
or someone else might pipe in).
In most cases for NetWare, just add the file to the appropriate unix dir and then add the file name to the corresponding NWGnuMakefile.
Lucian Adrian Grijincu
2007-06-06 22:08:05 UTC
Permalink
Post by William A. Rowe, Jr.
Post by Lucian Adrian Grijincu
I hear that there are real performance reasons to maintain
http://www.ops.ietf.org/lists/v6ops/v6ops.2003/msg01377.html
I first though we could do a strcmp to check for "127.0.0.1" or "::1",
but it's not going to work, because users may have altered the hosts
file to set a specific hostname to loopback and this code should be
able to get things like "localhost" as a valid parameter.
Correct, that won't work. Although looking for "127." or "::" prefixes
might be a legimate test, however "localhost" won't resolve.
Remember that setting up the loopback IP's .1, .2, .3, .4 all on the
same port might be a reasonable design of a local app and wouldn't pass
if you looked for the full loopback IP.
Post by Lucian Adrian Grijincu
1. kill AI_ADDRCONFIG for APR_UNSPEC
2. document "::1" and any other link-local addresses and hostnames as
invalid if APR_UNSPEC is used.
3. retry without AI_ADDRCONFIG if first try fails
1. BAD: this is the only place where AI_ADDRCONFIG is used and not
using it would mean a performance regression for applications that do
not care about loopback.
2. UGLY: APR should work arround platform specific issues and present
a simple interface. Having the user check for link-localness
beforehand is ... ugly. :)
3. GOOD: We already retry for some other errors and retrying would
a) link-local address or hostname. This should be resolved locally,
which means the drawback is little
"I can't find the hostname you specified", or (not very probable)
manage to find it at the second try
I've attached a patch against the tarball that does what's needed for 3.
finally, all test pass now :)
I'm quite partial to your third solution, I trust from performance that
this is the greatest net efficiency (but per platform tests would be needed
to confirm this). This is worth dumping 1.2.9 and rerolling 1.2.10 IMHO
(along with other small fixes that are identified today or tomorrow morning.)
Hi Bill,

Please look at the immensity of the patch I submitted:

339c339
< if ((error == EAI_BADFLAGS || error == EAI_ADDRFAMILY ) &&
family == APR_UNSPEC) {
---
Post by William A. Rowe, Jr.
if (error == EAI_BADFLAGS && family == APR_UNSPEC) {
which comes in this context:
error = getaddrinfo(hostname, servname, &hints, &ai_list);
#ifdef HAVE_GAI_ADDRCONFIG
if ((error == EAI_BADFLAGS || error == EAI_ADDRFAMILY ) && family
== APR_UNSPEC) {
/* Retry with no flags if AI_ADDRCONFIG was rejected. */
hints.ai_flags = 0;
error = getaddrinfo(hostname, servname, &hints, &ai_list);
}
#endif

I agree that this thing needs to be rechecked on all platforms, it's
just the sane thing to do, but I'd suggest that the 1.2.10 contain
this check and not dump the AI_ADDRCONFIG flag altogether.


Disclaimer: I haven't worked with autoconf automake etc. and I really
don't have the time :(

can someone please illuminate me what needs to be done to have a
single source file be compiled and linked on all platforms?

I'd like to see this:
http://mail-archives.apache.org/mod_mbox/apr-dev/200705.mbox/%***@mail.gmail.com%3e
included in APR. It's been discussed in december 2006 too:
http://mail-archives.apache.org/mod_mbox/apr-dev/200612.mbox/browser

It's an implementation of "rm -d -r" based only on APR objects.

--
Thank you,
Lucian Adrian Grijincu
Colm MacCarthaigh
2007-06-06 22:57:30 UTC
Permalink
Post by Lucian Adrian Grijincu
1. kill AI_ADDRCONFIG for APR_UNSPEC
In my opinion, AI_ADDRCONFIG is a useful default flag and prevents
unneccessary delay and lookups.
Post by Lucian Adrian Grijincu
2. document "::1" and any other link-local addresses and hostnames as
invalid if APR_UNSPEC is used.
This is not true, see my other mail.
Post by Lucian Adrian Grijincu
3. retry without AI_ADDRCONFIG if first try fails
This sucks. I prefer this:

4. Add APR_NUMERIC_ADDRESS, and set the AI_NUMERICHOST hint, when
passed *don't* set AI_ADDRCONFIG. Document that people who
want to perform a literal IP translation - regardless of
connectivity - should use it.

E.g., if I want to turn "::1" into a structure I can use
and I totally don't care if I have general IPv6 connectivity
or if I even have connectivity to ::1 itself, I should use this
flag.
--
Colm MacCárthaigh Public Key: colm+***@stdlib.net
Colm MacCarthaigh
2007-06-06 23:34:15 UTC
Permalink
<snip from=man getaddrinfo(3)>
If hints.ai_flags contains the
AI_NUMERICHOST flag then the node parameter must be a numerical
network
address. The AI_NUMERICHOST flag suppresses any potentially
lengthy
network host address lookups.
</snip>
how does this work with string names like "localhost" too?
Eh, it doesn't, that's why it's got the word numeric in there ;-) But if
people want to translate literal IP addresses into addrinfo structures
regardless of connectivity - that's how to do it.
As I understand the APR interface that's misbehaving now needs to
support hostnames besides IPs represented as strings.
Very much so, that's the majority use-case by a long long way, it works
fine btw!
Suppose that a this string is read from the commandline as a
parameter. The app coder cannot pass this new APR_NUMERIC_ADDRESS
flag, because he doesn't know if the string he received is a name for
a link-local IP.
Firstly: I'm not sure what your point here is :-) That wouldn't be the
use-case.

Secondly: It's incredibly trivial to tell if a string is a literal IP
address or not, they are programatically distinguishable from hostnames
with extreme ease. But it'd be a bad idea to do that, still not the
use-case!
--
Colm MacCárthaigh Public Key: colm+***@stdlib.net
Colm MacCarthaigh
2007-06-07 00:22:20 UTC
Permalink
You said (or so I understood) that APR should add a new flag
(APR_NUMERIC_ADDRESS) to it's API. When a programmer wants to use
"::1" in a call to apr_sockaddr_info_get, they should pass in this
flag as well, to be sure that the call succeeds on Ubuntu 7.04 32bit
too.
If we want to support this behaviour at all, we should. In general
though I'd have thought apr_inet_pton is sufficient, and that apr as a
whole does not need it. But for some reason folk seem to want
getaddrinfo("::1", ...) to magically work in spite of the what the RFCs
say , I'm just giving options here :-)
What would that programmer do if it had to pass a hostname to
apr_sockaddr_info_get and that name would point to "::1".
Just not set the flag, since it's not a numeric address.
I added this to my /etc/hosts "::1 my_name_lo"
and modified the testsocket.c file that failed replacing "::1" with
"my_name_lo".
https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828 some
explanation for this behaviour on this platform.)
But the test should fail in that scenario, I don't see a problem.
What good would APR_NUMERIC_ADDRESS do in this case?
Like I said, that is not the use-case.
--
Colm MacCárthaigh Public Key: colm+***@stdlib.net
Colm MacCarthaigh
2007-06-07 00:49:06 UTC
Permalink
a) either have different behaviour on different platforms (Ubuntu 7.4
(and everything based on it) vs. the rest).
AI_ADDRCONFIG behaviour is not supported on plenty of platforms yet,
yes, but it's backwards compatible, it's a safe default too, I
don't see how the difference in behaviour affects users of the API.
As long as you do:

linked-list-result = apr_sockaddr_info_get ("opaque-string")

foreach node in linked-list-result do:
listen() or connect()

there is no problem. The problem *only* arises if you use
apr_sockaddr_info_get("::1") and some kind of niaive "do I have working
IPv6" test. But it's a resolver, nothing else, that usage falls outside
of common or reasonable behaviour IMO.

On platforms that support the AI_ADDRCONFIG behaviour our users get to
avoid an unneccessary listen() or connect() call (and corresponding
delay and timeout). This is a big win!
b) or document that this function must not be used with strings
representing link-local IPv6 IPs or hostnames to link-local IPv6 IPs.
link-local addresses are something else again, but you can getaddrinfo()
a link-local address just fine, if you really want to. Don't expect it
to be very useful in a L3 application though!
Did I understand right?
No :-)
Post by Colm MacCarthaigh
What good would APR_NUMERIC_ADDRESS do in this case?
Like I said, that is not the use-case.
I first understood that you were referring to the use-case of
"hostnames to IPv6 link-local IPs" in relation to
apr_sockaddr_info_get, not APR_NUMERIC_ADDRESS. Sorry it's kindof
early in the morning on my side of the planet and I'm subject to
self-imposed sleep-deprivation.
I've never mentioned link-local IPs! The use-case I was responding about
is the one in the test, namely wanting "::1" to always resolve, no
matter what. That's a very special case (for which apr_inet_pton or an
entirely different approach are better suited).
--
Colm MacCárthaigh Public Key: colm+***@stdlib.net
Lucian Adrian Grijincu
2007-06-07 00:38:39 UTC
Permalink
Post by Colm MacCarthaigh
You said (or so I understood) that APR should add a new flag
(APR_NUMERIC_ADDRESS) to it's API. When a programmer wants to use
"::1" in a call to apr_sockaddr_info_get, they should pass in this
flag as well, to be sure that the call succeeds on Ubuntu 7.04 32bit
too.
If we want to support this behaviour at all, we should. In general
though I'd have thought apr_inet_pton is sufficient, and that apr as a
whole does not need it. But for some reason folk seem to want
getaddrinfo("::1", ...) to magically work in spite of the what the RFCs
say , I'm just giving options here :-)
What would that programmer do if it had to pass a hostname to
apr_sockaddr_info_get and that name would point to "::1".
Just not set the flag, since it's not a numeric address.
I added this to my /etc/hosts "::1 my_name_lo"
and modified the testsocket.c file that failed replacing "::1" with
"my_name_lo".
https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828 some
explanation for this behaviour on this platform.)
From this: " > But the test should fail in that scenario, I don't see
a problem." I understand that we:

a) either have different behaviour on different platforms (Ubuntu 7.4
(and everything based on it) vs. the rest).
b) or document that this function must not be used with strings
representing link-local IPv6 IPs or hostnames to link-local IPv6 IPs.

Did I understand right?
Post by Colm MacCarthaigh
What good would APR_NUMERIC_ADDRESS do in this case?
Like I said, that is not the use-case.
I first understood that you were referring to the use-case of
"hostnames to IPv6 link-local IPs" in relation to
apr_sockaddr_info_get, not APR_NUMERIC_ADDRESS. Sorry it's kindof
early in the morning on my side of the planet and I'm subject to
self-imposed sleep-deprivation.
Post by Colm MacCarthaigh
--
Lucian Adrian Grijincu
2007-06-07 00:06:10 UTC
Permalink
Post by Colm MacCarthaigh
<snip from=man getaddrinfo(3)>
If hints.ai_flags contains the
AI_NUMERICHOST flag then the node parameter must be a numerical network
address. The AI_NUMERICHOST flag suppresses any potentially
lengthy
network host address lookups.
</snip>
how does this work with string names like "localhost" too?
Eh, it doesn't, that's why it's got the word numeric in there ;-) But if
people want to translate literal IP addresses into addrinfo structures
regardless of connectivity - that's how to do it.
As I understand the APR interface that's misbehaving now needs to
support hostnames besides IPs represented as strings.
Very much so, that's the majority use-case by a long long way, it works
fine btw!
Suppose that a this string is read from the commandline as a
parameter. The app coder cannot pass this new APR_NUMERIC_ADDRESS
flag, because he doesn't know if the string he received is a name for
a link-local IP.
Firstly: I'm not sure what your point here is :-) That wouldn't be the
use-case.
You said (or so I understood) that APR should add a new flag
(APR_NUMERIC_ADDRESS) to it's API. When a programmer wants to use
"::1" in a call to apr_sockaddr_info_get, they should pass in this
flag as well, to be sure that the call succeeds on Ubuntu 7.04 32bit
too.

What would that programmer do if it had to pass a hostname to
apr_sockaddr_info_get and that name would point to "::1".

More verbose:
I added this to my /etc/hosts "::1 my_name_lo"
and modified the testsocket.c file that failed replacing "::1" with
"my_name_lo".
The test failed (on Ubuntu 7.04, see here:
https://bugs.launchpad.net/ubuntu/+source/netcfg/+bug/24828 some
explanation for this behaviour on this platform.)

What good would APR_NUMERIC_ADDRESS do in this case?

Or maybe I haven't understood what you were proposing ...

--
Lucian Adrian Grijincu
Post by Colm MacCarthaigh
Secondly: It's incredibly trivial to tell if a string is a literal IP
address or not, they are programatically distinguishable from hostnames
with extreme ease. But it'd be a bad idea to do that, still not the
use-case!
--
Lucian Adrian Grijincu
2007-06-06 23:06:49 UTC
Permalink
Post by Colm MacCarthaigh
Post by Lucian Adrian Grijincu
1. kill AI_ADDRCONFIG for APR_UNSPEC
In my opinion, AI_ADDRCONFIG is a useful default flag and prevents
unneccessary delay and lookups.
Post by Lucian Adrian Grijincu
2. document "::1" and any other link-local addresses and hostnames as
invalid if APR_UNSPEC is used.
This is not true, see my other mail.
Post by Lucian Adrian Grijincu
3. retry without AI_ADDRCONFIG if first try fails
4. Add APR_NUMERIC_ADDRESS, and set the AI_NUMERICHOST hint, when
passed *don't* set AI_ADDRCONFIG. Document that people who
want to perform a literal IP translation - regardless of
connectivity - should use it.
E.g., if I want to turn "::1" into a structure I can use
and I totally don't care if I have general IPv6 connectivity
or if I even have connectivity to ::1 itself, I should use this
flag.
--
<snip from=man getaddrinfo(3)>
If hints.ai_flags contains the
AI_NUMERICHOST flag then the node parameter must be a numerical network
address. The AI_NUMERICHOST flag suppresses any potentially lengthy
network host address lookups.
</snip>

how does this work with string names like "localhost" too?
As I understand the APR interface that's misbehaving now needs to
support hostnames besides IPs represented as strings.

Suppose that a this string is read from the commandline as a
parameter. The app coder cannot pass this new APR_NUMERIC_ADDRESS
flag, because he doesn't know if the string he received is a name for
a link-local IP.
Jeff Trawick
2007-06-08 20:36:33 UTC
Permalink
Post by Colm MacCarthaigh
Post by Lucian Adrian Grijincu
1. kill AI_ADDRCONFIG for APR_UNSPEC
In my opinion, AI_ADDRCONFIG is a useful default flag and prevents
unneccessary delay and lookups.
+1
Post by Colm MacCarthaigh
4. Add APR_NUMERIC_ADDRESS, and set the AI_NUMERICHOST hint, when
passed *don't* set AI_ADDRCONFIG. Document that people who
want to perform a literal IP translation - regardless of
connectivity - should use it.
E.g., if I want to turn "::1" into a structure I can use
and I totally don't care if I have general IPv6 connectivity
or if I even have connectivity to ::1 itself, I should use this
flag.
+1
Joe Orton
2007-06-06 16:42:25 UTC
Permalink
Post by Lucian Adrian Grijincu
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
./configure
make
make test
testsockets : \/bin/bash: line 1: 10039 Segmentation fault
(core dumped) ./$prog
This is probably IPv6 related; does "modprobe ipv6" make a difference;
did 1.2.8 fail similarly?
Post by Lucian Adrian Grijincu
Still haven't checked if this is to be expected running ./test/testall
You'll get random failures if you run testall from outside the test
directory, yes.

joe
William A. Rowe, Jr.
2007-06-06 21:19:45 UTC
Permalink
Post by Lucian Adrian Grijincu
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
./configure
make
make test
testsockets : \/bin/bash: line 1: 10039 Segmentation fault
(core dumped) ./$prog
the line possition it reports differs from run to run.
Same system: Ubuntu 7.04, 32bit.
testatomic : SUCCESS
testdir : SUCCESS
testdso : FAILED 8 of 9
testdup : SUCCESS
testenv : SUCCESS
testfile : SUCCESS
testfilecopy : FAILED 2 of 4
testfileinfo : SUCCESS
testflock : FAILED 2 of 3
testfmt : SUCCESS
testfnmatch : FAILED 2 of 2
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testlfs : SUCCESS
testmmap : |Segmentation fault (core dumped)
Even though they pass when run from make check.
Yow :(

would you try running within gdb and give us the where's? You might
need to recompile with CFLAGS=-g for debugging symbols.

Bill
Lucian Adrian Grijincu
2007-06-06 21:32:32 UTC
Permalink
Post by William A. Rowe, Jr.
Post by Lucian Adrian Grijincu
I took http://apr.apache.org/dev/dist/apr-1.2.9.tar.gz
Hope I'm on target now:)
I've done two tests. One in which I ran buildconf myself and one without.
./configure
make
make test
testsockets : \/bin/bash: line 1: 10039 Segmentation fault
(core dumped) ./$prog
the line possition it reports differs from run to run.
Same system: Ubuntu 7.04, 32bit.
testatomic : SUCCESS
testdir : SUCCESS
testdso : FAILED 8 of 9
testdup : SUCCESS
testenv : SUCCESS
testfile : SUCCESS
testfilecopy : FAILED 2 of 4
testfileinfo : SUCCESS
testflock : FAILED 2 of 3
testfmt : SUCCESS
testfnmatch : FAILED 2 of 2
testargs : SUCCESS
testhash : SUCCESS
testipsub : SUCCESS
testlock : SUCCESS
testlfs : SUCCESS
testmmap : |Segmentation fault (core dumped)
Even though they pass when run from make check.
Yow :(
would you try running within gdb and give us the where's? You might
need to recompile with CFLAGS=-g for debugging symbols.
Bill
Sorry,
I was sleepy and unattentive:
testall is supposed to be run from the test/ subdirectory.
I ran it as ./test/testall, with chdir being the apr directory, not
it's test subdir.

Nothing to see here, please move along :)

See my other mail: with the patch applied all tests succeed.
(still if I run testall from apr and not apr/test/ some tests fail,
but I think it's in the test design to be so).

--
Lucian Adrian Grijincu
William A. Rowe, Jr.
2007-06-06 21:36:51 UTC
Permalink
Post by William A. Rowe, Jr.
would you try running within gdb and give us the where's? You might
need to recompile with CFLAGS=-g for debugging symbols.
someday I'll learn to read forward to the end before clicking send on
the smaller random replies :) Nicely done with your diagnostics. On the
subject of apr - you need to cd test and then ./testall from within that
directory, just as 'make check' does.
Joe Orton
2007-06-06 16:37:32 UTC
Permalink
Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[+1] apr-0.9.14
[+1] apr-1.2.9
These both show no regressions on Linux/i386 and x86_64.

w.r.t. APR_HAS_LARGE_FILES, please see list archives for rationale, it
is defined as intended; yes the testlfs error message is poor for the
!lfs case

joe
Bojan Smojver
2007-06-06 21:21:31 UTC
Permalink
Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[+1] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
Fedora 7 i386 and x86_64.

PS. Thanks everyone for clearing up the APR_HAS_LARGE_FILES thing.
--
Bojan
William A. Rowe, Jr.
2007-06-12 06:41:21 UTC
Permalink
Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[ ] apr-0.9.14
[ ] apr-1.2.9
[ ] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
We are at 2x +1 for apr 0.9.14 and apr 1.2.9

We are at no votes for apr-iconv 1.2.0.

It seems most of the concerns are addressed, and while worth addressing,
not necessary for this release.

Votes, please, folks? And while we are on the subject, note the subj
says [vote] - not [discuss] :) Please use appropriate subject renames
when you launch off on a tangent/report build failures.

Bill
Sander Temme
2007-06-12 06:57:17 UTC
Permalink
Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[+1] apr-0.9.14
[+1] apr-1.2.9
[+1] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
FreeBSD 6.1 and 4.11, see below. +1 for release. Both FreeBSDs have
their (VMWare) interface configured with link-local IPv6 in addition
to IPv4.

S.


--------

All built with ./configure --prefix=something --enable-nonportable-
atomics

FreeBSD freebsd6.sandla.org. 6.1-RELEASE FreeBSD 6.1-RELEASE #0: Wed
Nov 29 12:51:00 PST 2006 ***@freebsd6.sandla.org.:/usr/obj/usr/
src/sys/SMP amd64

This is a single CPU VMWare instance with 256Mb of memory on a dual
AMD64 Penguin Computing box.
Post by William A. Rowe, Jr.
This program won't work on this platform because there is no
support for threads.
This program won't work fully on this platform because there is no
support for threads.
Failed
oldval =0 should be zero
Failed.
testing apr_atomic_dec ***
Error code 255
Stop in /x1/sctemme/apr/build/apr-0.9.14/test.
*** Error code 1
Stop in /x1/sctemme/apr/build/apr-0.9.14.
AFAIK threads are OK in FreeBSD 6. No regression from 0.9.13.

apr-1.2.9 make check: All tests passed.
This died somewhere in or after the lock performance tests on 1.2.8

apr-iconv-1.2.0 has no make check target or discernable tests, and
neither did 1.1.1

FreeBSD freebsd4.sandla.org. 4.11-RELEASE FreeBSD 4.11-RELEASE #0:
Wed Nov 29 19:16:35 PST 2006 ***@freebsd4.sandla.org.:/usr/obj/
usr/src/sys/FREEBSD4 i386

apr-0.9.14: same failure as above
apr-1.2.9: All tests passed.
--
Sander Temme
***@apache.org
PGP FP: 51B4 8727 466A 0BC3 69F4 B7B8 B2BE BC40 1529 24AF
William A. Rowe, Jr.
2007-06-14 18:47:16 UTC
Permalink
Post by Sander Temme
Post by William A. Rowe, Jr.
http://apr.apache.org/dev/dist/
+/-1? Package to release
[+1] apr-0.9.14
[+1] apr-1.2.9
[+1] apr-iconv-1.2.0
Three packages so far to consider, votes welcome
FreeBSD 6.1 and 4.11, see below. +1 for release. Both FreeBSDs have
their (VMWare) interface configured with link-local IPv6 in addition to
IPv4.
Thanks Sander.

That's +4 for apr's (+5 once I vote), +1 for apr-iconv (+2 once I vote).

I'll chime in and close this round of release votes once I have
one more +/- apr-iconv 1.2.0.

Bill
William A. Rowe, Jr.
2007-06-17 23:30:48 UTC
Permalink
Post by William A. Rowe, Jr.
That's +4 for apr's (+5 once I vote), +1 for apr-iconv (+2 once I vote).
I'll chime in and close this round of release votes once I have
one more +/- apr-iconv 1.2.0.
Ping?
Bojan Smojver
2007-06-18 07:29:52 UTC
Permalink
Post by William A. Rowe, Jr.
[+1] apr-iconv-1.2.0
Fedora 7, i386, builds against APR 1.2.9 (both against APR build tree
and installed APR).

One note, though. Without --prefix option to configure, the build fails
with:
-----------------------------------------------
/bin/sh /home/users/bojan/aa/apr-1.2.9/libtool --mode=link gcc -g -O2
-pthread -DHAVE_CONFIG_H -DLINUX=2 -D_REENTRANT -D_GNU_SOURCE
-D_LARGEFILE64_SOURCE -I/home/users/bojan/aa/apr-iconv-1.2.0/lib
-I/home/users/bojan/aa/apr-iconv-1.2.0/include
-I/home/users/bojan/aa/apr-1.2.9/include -module -avoid-version -rpath
NONE/lib/iconv -o iso-8859-1.la iso-8859-1.lo
libtool: link: only absolute run-paths are allowed
-----------------------------------------------

Looks like default prefix was set to NONE (literally). Not sure if this
is intentional or not.
--
Bojan
William A. Rowe, Jr.
2007-06-21 06:12:27 UTC
Permalink
Post by William A. Rowe, Jr.
[+1] apr-iconv-1.2.0
And +1 to all three packages, here.

I'm finally in one place, with connectivity, at last. I'll stage these
all up with updated web content tomorrow (and probably tackle placing
our status reports on the /dev/ site as well.)

Bill
William A. Rowe, Jr.
2007-06-21 22:43:30 UTC
Permalink
Post by Bojan Smojver
Post by William A. Rowe, Jr.
[+1] apr-iconv-1.2.0
Fedora 7, i386, builds against APR 1.2.9 (both against APR build tree
and installed APR).
One note, though. Without --prefix option to configure, the build fails
Looks like default prefix was set to NONE (literally). Not sure if this
is intentional or not.
Idea; should we default --prefix to the apr-1-config's prefix?

Bill

Continue reading on narkive:
Loading...