Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#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

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

Child Tickets

Change History (13)

comment:1 Changed 7 years ago by 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)

comment:2 Changed 7 years ago by 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...

comment:3 Changed 7 years ago by Sebastian

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

comment:4 Changed 7 years ago by 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).

comment:5 Changed 7 years ago by Sebastian

Status: newneeds_review

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

comment:6 Changed 7 years ago by nickm

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

comment:7 Changed 7 years ago by 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.

comment:8 Changed 7 years ago by nickm

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 7 years ago by 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.

comment:10 Changed 7 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

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 in reply to:  10 Changed 7 years ago by 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.

comment:12 Changed 7 years ago by nickm

Keywords: tor-client added

comment:13 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.