View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004047 | unreal | installing | public | 2011-11-06 11:42 | 2011-11-15 18:04 |
| Reporter | samu | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.9 | ||||
| Summary | 0004047: configure fails when cannot list PATH directories. | ||||
| Description | when as_test_x is set to: eval sh -c ' if test -d "$1"; then test -d "$1/."; else case $1 in #( -*)set "./$1";; esac; case `ls -ld "$1" 2>/dev/null` in #(( ???[sx]*):;;*)false;;esac;fi ' sh it fails to find any binary. The same occurs in extras/c-ares-1.7.3/configure - it cannot find sed, but it overrides its configure file each time I invoke the main configure script, so I cannot patch it there. The funny part is, that when I actually fix all these issues, there comes more: checking for gethostbyname in -lnsl... no checking for gethostbyname in -lsocket... no checking for gethostbyname with both nsl and socket libs... no checking for gethostbyname for Minix 3... Syntax error: end of file unexpected (expecting ")") no checking for gethostbyname for eCos... Syntax error: end of file unexpected (expecting ")") no checking for gethostbyname in -lnet... no configure: error: couldn't find libraries for gethostbyname() | ||||
| Steps To Reproduce | I guess that the user has to be unable to stat() the '/' directory, as test -x / runs fine. | ||||
| Additional Information | I managed to patch the configure script, so that it would find all required binaries correctly, but I cannot patch c-ares configure file, which fails to find sed. For some reason, this file is overwritten every time I invoke Config/configure. Instead, I have written a small script which would prepare the environment to launch c-ares configure: #!/bin/sh for i in \ \ rm \ grep \ sed \ ar \ ; do echo export "`echo $i |tr [a-z] [A-Z]`=`whereis $i |awk '{print $2}'`"; done | ||||
| Attached Files | configure.patch (155 bytes) | ||||
| 3rd party modules | |||||
|
|
Forgot to add - this is on FreeBSD, and using ugidfw to forbid stat() on these directories. System version is unrelated. |
|
|
This bug sounds like something that should be fixed in autoconf, not unrealircd, if at all. We will not patch ./configure because it is built from configure.ac using autoconf. And when you do create patches, please use the unified diff format ;-). Also, it appears that you created the patch backwards... (i.e., a patch that undoes the changes you made instead of doing them)? > but I cannot patch c-ares configure file, which fails to find sed. > For some reason, this file is overwritten every time I invoke Config/configure. That is because unrealircd's ./configure does ugly stuff like building c-ares. You have to update extras/c-ares.tar.gz with your changes to c-ares's configure or use --with-system-cares when building unrealircd. You can also always manually install c-ares into your home directory and still use --with-system-cares to link against it, just set PKG_CONFIG_PATH correctly or set CARES_CFLAGS and CARES_LIBS properly when using unrealircd's ./configure with --with-system-cares. EDIT: spelling |
|
|
Now I actually think that this is not related to permissions - when I tried to build unreal WITHOUT c-ares and remote includes, it went just fine (on the same environment). Yeah, I screwed the patch, it was made so quickly that I didn't checked it ;-) |
|
|
> I guess that the user has to be unable to stat() the '/' directory, as test -x / runs fine. I still do not understand this. If `test -x /' returns success, then why does this bug exist at all? Also, your patch adds calls to binaries which are not guaranteed to exist on various systems. The best way to work around your problem might be to instead assume that the user has execute permissions for the local directory, i.e., `test -x .' instead of `test -x /'. How are you building unrealircd without c-ares? And are you using your patched ./configure still or the original? |
|
|
Okay, sorry, this time it was my mistake. It configured fine, because I forgot to load MAC bsdextended policy, and the user had default system access to all binaries (including /). So it's not related to c-ares, after all, my bad. I use the original configure. |
|
|
Please open a new bug if there are still issues of a different sort. I still have no idea what you're doing :-p. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2011-11-06 11:42 | samu | New Issue | |
| 2011-11-06 11:42 | samu | File Added: configure.patch | |
| 2011-11-06 14:05 | samu | Note Added: 0016776 | |
| 2011-11-14 04:43 | ohnobinki | Note Added: 0016788 | |
| 2011-11-14 04:44 | ohnobinki | Note Edited: 0016788 | |
| 2011-11-14 20:31 | samu | Note Added: 0016789 | |
| 2011-11-15 00:47 | ohnobinki | Note Added: 0016790 | |
| 2011-11-15 16:22 | samu | Note Added: 0016791 | |
| 2011-11-15 18:04 | ohnobinki | Note Added: 0016792 | |
| 2011-11-15 18:04 | ohnobinki | Status | new => closed |
| 2011-11-15 18:04 | ohnobinki | Resolution | open => no change required |
