1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
## <a name="Table_of_Contents"> Table of Contents </a>
%TOC%
## <a name="Overview"> Overview </a>
This is a recompilation of common porting problems and their solutions. Information is gathered from the following sources:
[Debian GNU/Hurd port guidelines](http://www.debian.org/ports/hurd/hurd-devel-debian/)
[James Morrison's GNU/Hurd pages](http://hurd.dyndns.org/)
as well as other misc. sources.
First of all, see [BtsFiling](http://www.vmlinux.org/twikihttp://LOCATIONHurd/BtsFiling) if you need instructions on manipulating [Debian](http://www.debian.org/) source packages and submitting patches to their [Bug Tracking System](http://bugs.debian.org/).
## <a name="Missing_pthreads"> Missing pthreads </a>
You can try out Neal Walfields implementation of libpthreads. It will server as our pthreads library until "the one pthreads that will rule them all" in [[GLibC]] has native support on the Hurd. Quote is from the mailing lists by Roland [[McGrath]].
Neal's lastest tar balls of libpthreads is available at:
* <ftp://web.walfield.org/pub/people/neal/hurd/libpthread/>
## <a name="Undefined_PIPE_BUF"> </a> Undefined PIPE\_BUF
Change it to use sysconf(\_SC\_PIPE\_BUF) #ifndef PIPE\_BUF. (from a Roland McGrath message in debian-hurd)
## <a name="Bad_File_Descriptor"> Bad File Descriptor </a>
If you get Bad File Descriptor error when trying to read from a file (or accessing it at all), check the open() invocation. The second argument is the access method. If it is a hard coded number instead of a symbol defined in the standard header files, the code is screwed and should be fixed to either use O\_RDONLY, O\_WRONLY or O\_RDWR. This bug was observed in the fortunes and mtools packages for example.
## <a name="PATH_MAX"> </a> PATH\_MAX
Every unconditionalized use of PATH\_MAX is a POSIX incompatibility. If there is no upper limit on the length of a path, this symbol is not defined in any header file. Instead, you need to either use a different implementation that does not rely on the length of a string or use sysconf() to query the length at runtime. If sysconf() returns -1, you have to use realloc() to allocate the needed memory dynamically.
## <a name="MAX_PATH"> </a> MAX\_PATH
same as PATH\_MAX
## <a name="MAXPATHLEN"> </a> MAXPATHLEN
same as PATH\_MAX
## <a name="MAXHOSTNAMELEN"> </a> MAXHOSTNAMELEN
same as PATH\_MAX. Neal's [xgethostname function](http://ftp.walfield.org/pub/people/neal/xgethostname/) can help.
## <a name="NOFILE"> </a> NOFILE
Replace with RLIMIT\_NOFILE
## <a name="GNU_specific_define"> </a> GNU specific #define
If you need to include specific code for the Hurd using #if...#endif, then you can use the **_GNU_** symbol to do so. But think (at least) thrice! before doing so. In most situations, this is completely unnecessary and will create more problems than it may solve. Better ask on the mailing list how to do it right if you can't think of a better solution.
## <a name="sys_errlist_vs_strerror_"> sys\_errlist[] vs. strerror() </a>
If a program has only support for sys\_errlist[] you will have to do some work to make it compile on GNU, which has dropped support for it and does only provide strerror(). Steinar Hamre writes about strerror():
strerror() should be used because:
* It is the modern, POSIX way.
* It is localized.
* It handles invalid signals/numbers out of range. (better errorhandling and not a buffer-overflow-candidate/security risk)
strerror() should always be used if it is available. Unfortunaly there are still some old non-POSIX systems that do not have strerror(), only sys\_errlist[].
Today, only supporting strerror() is far better than only supporting sys\_errlist[]. The best (from a portability viewpoint), however is supporting both. For configure.in, you will need:
AC\_CHECK\_FUNCS(strerror)
To config.h.in, you need to add:
#undef HAVE\_STRERROR
Then something like:
#ifndef HAVE_STRERROR
static char *
private_strerror (errnum)
int errnum;
{
extern char *sys_errlist[];
extern int sys_nerr;
if (errnum > 0 && errnum <= sys_nerr)
return sys_errlist[errnum];
return "Unknown system error";
}
#define strerror private_strerror
#endif /* HAVE_STRERROR */
You can for example look in the latest fileutils (the above is a simplified version of what I found there.) Patches should of course be sent to upstream maintainers, this is very useful even for systems with a working sys\_errlist[].
Of course, if you don't care about broken systems (like MS-DOG) not supporting strerror() you can just replace sys\_errlist[] directly (upstream might not accept your patch, but debian should have no problem)
## <a name="Filenames_ending_in_a_slash_"> Filenames ending in a slash \`/' </a>
Those are evil if they don't exist and you want to name a directory this way. For example, mkdir foobar/ will not work on GNU. This is POSIX compatible. POSIX says that the path of a directory may have slashes appended to it. But the directory does not exist yet, so the path does not refer to a directory, and hence trailing slashes are not guaranteed to work. Just drop the slashes, and you're fine.
## <a name="Missing_termio_h"> Missing termio.h </a>
Change it to use termios.h (check for it properly with autoconf HAVE\_TERMIOS\_H or the **_GLIBC_** macro)
## <a name="AC_HEADER_TERMIO"> AC\_HEADER\_TERMIO </a>
The autoconf check for AC\_HEADER\_TERMIO tryes to check tfor termios, but it's only really checking for termio in termios.h. It is better to use AC\_CHECK\_HEADERS(termio.h termios.h)
-- [[Main/RobertMillan]] - 22 Jul 2002
Formatting and minor grammatical fixes.
-- [[Main/JoachimNilsson]] - 09 Sep 2002
Added more examples and misc semantical fixes.
-- [[Main/RobertMillan]] - 05 Oct 2002
|
