#5355 closed defect (fixed)
FTBFS on hurd
Reported by: | weasel | Owned by: | |
---|---|---|---|
Priority: | Medium | Milestone: | Tor: 0.2.3.x-final |
Component: | Core Tor/Tor | Version: | Tor: 0.2.3.11-alpha |
Severity: | Keywords: | tor-client | |
Cc: | Actual Points: | ||
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description
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
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
Child Tickets
Change History (13)
comment:1 Changed 8 years ago by
comment:2 Changed 8 years ago by
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...
comment:4 Changed 8 years ago by
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).
comment:5 Changed 8 years ago by
Status: | new → needs_review |
---|
I think I have a patch, should be rather trivial. See bug5355 in my repo
comment:6 Changed 8 years ago by
Looks okay, I think. Did we make sure that getcwd actually reports ERANGE correctly on all the platforms we care about?
comment:7 Changed 8 years ago by
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.
comment:8 Changed 8 years ago by
Milestone: | → Tor: 0.2.3.x-final |
---|
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?
comment:9 Changed 8 years ago by
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.
comment:10 follow-up: 11 Changed 8 years ago by
Resolution: | → fixed |
---|---|
Status: | needs_review → closed |
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?
comment:11 Changed 8 years ago by
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.
comment:12 Changed 7 years ago by
Keywords: | tor-client added |
---|
comment:13 Changed 7 years ago by
Component: | Tor Client → Tor |
---|
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)