FTBFS on hurd

[weasel]

starting in 0.2.3.11, tor fails to build from source on the hurd.

This might also be a change in environment rather than a change in tor that causes it to fail now.

make[4]: Entering directory `/build/buildd-tor_0.2.3.12-alpha-1-hurd-i386-9yxbax/tor-0.2.3.12-alpha/src/common'
gcc -DHAVE_CONFIG_H -I. -I../..   -I../../src/common     -fPIE  -fstack-protector --param ssp-buffer-size=4  -D_FORTIFY_SOURCE=2  -Wformat -Wformat-security -Werror=format-security  -O2 -Wall -fno-strict-aliasing -MT address.o -MD -MP -MF .deps/address.Tpo -c -o address.o address.c
mv -f .deps/address.Tpo .deps/address.Po
gcc -DHAVE_CONFIG_H -I. -I../..   -I../../src/common     -fPIE  -fstack-protector --param ssp-buffer-size=4  -D_FORTIFY_SOURCE=2  -Wformat -Wformat-security -Werror=format-security  -O2 -Wall -fno-strict-aliasing -MT compat.o -MD -MP -MF .deps/compat.Tpo -c -o compat.o compat.c
compat.c: In function 'make_path_absolute':
compat.c:1641:13: error: 'PATH_MAX' undeclared (first use in this function)
compat.c:1641:13: note: each undeclared identifier is reported only once for each function it appears in
compat.c:1641:8: warning: unused variable 'path' [-Wunused-variable]
make[4]: *** [compat.o] Error 1
make[3]: *** [all-recursive] Error 1

from
​https://buildd.debian.org/status/fetch.php?pkg=tor&arch=hurd-i386&ver=0.2.3.12-alpha-1&stamp=1329410988

Earlier builds that made it past this are for instance
​https://buildd.debian.org/status/fetch.php?pkg=tor&arch=hurd-i386&ver=0.2.3.10-alpha-1&stamp=1324069107

[Sebastian]

Hrm, according to ​http://www.gnu.org/software/hurd/community/gsoc/project_ideas/maxpath.html we're violating posix by using PATH_MAX without making sure it's defined.

This is not a change in the environment, this is a new tor bug, introduced in a1c1fc72d17e0327093a63f20e56292cbac0cf39 ( Prepend cwd for relative config file paths. by Kamran Riaz Khan)

[Sebastian]

We use MAX_PATH in the code without issue elsewhere. Maybe the patch is as easy as changing PATH_MAX into MAX_PATH? Tho I don't see what exactly lets us get away with that...

[Sebastian]

oh, brainfart. We use MAX_PATH on Windows, of course.

[Sebastian]

Some systems provide an extension to posix getcwd that makes it malloc a large enough string. I considered making that functionality available everywhere, but it seems not worth it, because we don't use getcwd in other places (except in one case for Windows, but MAX_PATH works there).

[Sebastian]

I think I have a patch, should be rather trivial. See bug5355 in my repo

[nickm]

Looks okay, I think. Did we make sure that getcwd actually reports ERANGE correctly on all the platforms we care about?

[Sebastian]

I tested it on OSX, and it worked there. I didn't test other platforms, but checked linux and free/openbsd manpages and they say ERANGE gets reported.

[nickm]

Looks good! Best practice suggestsq that we need to have a real max path length, so that path_length *= 2 can't overflow. Also, let's pull this malloc-getcwd business out into a separate function.

Please have a look at branch "bug5355_nm" in my public repository?

[ln5]

Looks sane. I'd prefer a single return point from alloc_getcwd()
though, which saves us from stomping on errno too. See bug5355_ln in
my public repo.

[nickm]

Thanks, it looks good to me: merging it all.

(Technically, you don't need a "path=NULL" after tor_free(), since tor_free() sets its lvalue argument to NULL.)

I'm closing this for now. weasel, please reopen if this does not fix the hurd build?

[ln5]

Replying to nickm:

(Technically, you don't need a "path=NULL" after tor_free(), since tor_free() sets its lvalue argument to NULL.)

tor_free() is a macro! YUCK!

I didn't expect that at all. I'll be more suspicious in the future.