Bug 120793 – [GTK] GlibUtilities: getCurrentExecutablePath() does not compile on GNU/Hurd

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Alberto Garcia]

That's because PATH_MAX is not defined there.

Reported in Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=669059

[Alberto Garcia]

Created attachment 210658 [details]
Patch

[WebKit Commit Bot]

Attachment 210658 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WTF/ChangeLog', u'Source/WTF/wtf/gobject/GlibUtilities.cpp']" exit_code: 1
Source/WTF/wtf/gobject/GlibUtilities.cpp:43:  Weird number of spaces at line-start.  Are you using a 4-space indent?  [whitespace/indent] [3]
Total errors found: 1 in 2 files


If any of these errors are false positives, please file a bug against check-webkit-style.

[Alberto Garcia]

Created attachment 210660 [details]
Patch

The previous patch needed style fixes, here's the updated one.

[Sergio Villar Senin]

Comment on attachment 210660 [details]
Patch

I see how this could help with the build, but IMO the patch should actually fix the underlying issue. I believe there should be a way in GNU/Hurd to retrieve the current executable path even if PATH_MAX is not defined.

[Emilio Pozuelo Monfort]

There's currently no way to get the executable path on GNU/Hurd (there is /proc/self but there's no /proc/self/exe), but the catch-all case in findWebKitProcess() which just uses LIBEXECDIR should work fine there.

If you want we can keep a downstream patch with a dummy getCurrentExecutablePath() until there's a way to get the executable path on the Hurd.

[Gustavo Noronha (kov)]

Comment on attachment 210660 [details]
Patch

No point in waiting, I think, let's just do it and we can revisit if it is made possible in the future.

[Alberto Garcia]

Committed r155193: <http://trac.webkit.org/changeset/155193>