-
Notifications
You must be signed in to change notification settings - Fork 42
/
Copy pathporting.html
513 lines (486 loc) · 26.5 KB
/
porting.html
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
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<meta name="resource-type"
content="document">
<meta name="description"
CONTENT="How to make an OpenBSD port">
<meta name="keywords"
content="openbsd,ports">
<meta name="distribution"
content="global">
<meta name="copyright"
content="This document copyright 1997-2009 by OpenBSD.">
<title>Das Erzeugen einer OpenBSD-Portierung</title>
<link rev="made" HREF="mailto:[email protected]">
</head>
<body text="#000000" bgcolor="#FFFFFF" link="#23238E">
<a href="index.html"><img alt="[OpenBSD]" height="30" width="141" src="../images/smalltitle.gif" border="0"></a>
<h2><font color="#e00000">Das Erzeugen eines OpenBSD-Portierung</font></h2>
Du hast also gerade dein Lieblingssoftwarepaket auf deiner
OpenBSD-Maschine kompiliert und möchtest deinen Erfolg mit anderen
teilen, indem du davon eine Standard-Portierung machst? Was also ist
jetzt zu tun?
<p>
Die wichtigste Sache, die du machen solltest, ist mit anderen zu
<strong>kommunizieren</strong>. Frage die anderen Leute auf
<a href="mailto:[email protected]">[email protected]</a>, ob sie an
derselben Portierung arbeiten. <em>Teile es dem ursprünglichen Programmierer
mit</em>, inklusive der Probleme, wenn du welche findest. Wenn die
Lizenzbedingungen nicht korrekt sind, sag es ihm. Wenn du große
Schwierigkeiten hattest, die Portierung zum Laufen zu kriegen, teile ihm
mit, was verbessert werden könnte. Wenn sie nur auf Linux entwickeln
und den Rest der Unix-Welt ignorieren, versuche, ihre Sichtweise
etwas zu erweitern.
<p>
<strong>KOMMUNIKATION</strong> macht den Unterschied zwischen einer
erfolgreichen Portierung und einer Portierung, die langsam von allen alleine
gelassen und nicht mehr benutzt wird, aus.
<p>
Sieh dir zuerst die Portierungsinformationen auf dieser Seite an.
Dann überprüfe all die gelinkten Dokumente, insbesondere die
OpenBSD-Porting-<a href="../porting/checklist.html">Checkliste</a>.
<p>
<a href="../porting/porttest.html">Teste</a>, teste nochmal und
schlussendlich teste nochmals!
<p>
OpenBSD unterstützt Updates nun vollständig. Dies bedeutet, dass
<a href="../porting/de/update.html">ein paar Sonderfälle</a>
berücksichtigt werden müssen.
<p>
Liefere die Portierung aus (submit). Erzeuge einen ,gzipped tarball' des
Verzeichnisses der Portierung. Du kannst diesen entweder auf einen
öffentlichen FTP- oder HTTP-Server legen und die Adresse an
<a href="mailto:[email protected]">[email protected]</a> mailen
oder ,mime encoded' an die selbe Adresse schicken. Wähle
einfach eine Methode aus.
<p>
Neue Software zu portieren nimmt Zeit in Anspruch. Schwerer ist es
allerdings, diese danach weiterhin zu verwalten. Es ist schon in
Ordnung, wenn du Software portierst und die Verwaltung Anderen
überlässt. Es ist ebenfalls in Ordnung, wenn du Anderen bei der
Aktualisierung und Verwaltung anderer Portierungen hilfst, so lange du
mit ihnen in Verbindung bleibst, damit nicht die gleiche Arbeit
mehrmals gemacht wird.
<p>
In der OpenBSD-Kultur zählt »<code>MAINTAINER</code>ship« (auf
Deutsch Betreuung) nicht als Statussymbol sondern als Verantwortung.
Wir verwenden CVS und die Kommentare werden verwendet, um die Person
zu vermerken, die die Arbeit gemacht hat. Ein
Portierungs-<code>MAINTAINER</code> ist jemand anderes: eine Person,
die sich der Funktionalität der Portierungs verpflichtet fühlt und bereit
ist, Zeit zu investieren, um diese so gut es geht bereitzustellen.
<h3><font color="#0000e0">Index der Portierungsdokumentation</font></h3>
<ul>
<li><a href="#Avail">Verfügbare Portierungsinformation</a></li>
<li><a href="#Policy">OpenBSD-Portierungsrichtlinie</a></li>
<li><a href="#Security">Sicherheitsemfpehlungen</a></li>
<li><a href="#Generic">Allgemeine Portierungshinweise</a></li>
<li><a href="#Other">Andere hilfreiche Hinweise</a></li>
</ul>
<h3><font color="#0000e0"><a name="Avail">Verfügbare Portierungsinformation</a></font></h3>
<ul>
<li>OpenBSD-Portierungs-<a href="../porting/checklist.html">Checkliste</a>.
<li>OpenBSDs <a href="../porting/de/update.html">Updaterichtlinien</a>
für Portierungen.
<li>Die Handbuchseite
<a href="http://www.openbsd.org/cgi-bin/man.cgi?query=bsd.port.mk&sektion=5">bsd.port.mk(5)</a>.
Sie dokumentiert das Makefile der Portierungs-Infrastruktur, das am
Ende jeder individuellen Portierungs-Makefile eingeschlossen wird.
Es gibt am Anfang noch ein paar Kommentare innerhalb der Datei
selbst, aber die meisten der sinnvollen Informationen sind jetzt
dokumentiert.
<li>Einige Unterschiede zu den anderen BSD-Portierungssystemen,
hauptsächlich eine Zusammenfassung
der <a href="../porting/de/diffs.html">Infrastruktur-Unterschiede</a>.
<li><a href="../porting/de/libraries.html">Das Benutzen von Shared
Librarys in OpenBSD-Portierungen</a>. Die Regeln sind <strong>sehr wichtig
</strong> sobald du Shared Librarys benutzt.
<li><a href="../porting/de/autoconf.html">GNU-autoconf-Spezifikationen</a>,
wie man sie im Gebrauch mit OpenBSD-Portierungen handhabt.
<li><a href="../porting/de/config.html">Konfigurationsdateien</a>,
ein häufiger Stolperstein für neue Entwickler und die
einzigartigen Werkzeuge, die der OpenBSD-Portierungsbaum besitzt, um
diese zu verarbeiten.
<li><a href="../porting/audio-port.html">Das Portieren von
Audio-Applikationen auf OpenBSD</a>.
<li>Die
<a href="http://www.netbsd.org/Documentation/software/packages.html">
NetBSD Paketsystem</a>-Dokumentation. Dieses Dokument
beschreibt die NetBSD-Version des FreeBSD-Portierungssystems und ist
recht hilfreich.
<li>Das
<a href="http://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/index.html">FreeBSD
Porter's Handbook</a>. Das ist die FreeBSD-Portierungs-Bibel.
<li>Die OpenBSD-Portierungs-Mailingliste
<a href="mailto:[email protected]">[email protected]</a>.
</ul>
<h3><font color="#0000e0"><a name="Policy">OpenBSD-Portierungsrichtlinie</a></font></h3>
<ul>
<li>OpenBSD benutzt NICHT <code>/usr/local/etc/rc.d</code>.<br>
<code>/usr/local</code> wird dank NFS oftmals von verschiedenen
Maschinen benutzt. Aus diesem Grund können
Konfigurationsdateien, die spezifisch für eine bestimmte
Maschine sind, auch nicht in <code>/usr/local</code> abgelegt
werden, <code>/etc</code> ist die zentrale Lagerstätte für
individuelle Maschinen-Konfigurationsdateien.
Außerdem ist es eine OpenBSD-Richtlinie, niemals Dateien unter
<code>/etc</code> automatisch upzudaten. Portierungen, die ein
bestimmtes Boot-Setup benötigen, sollten den Administrator
anweisen, was zu tun ist, anstatt blind Dateien zu
installieren.
<li>OpenBSD komprimiert KEINE Handbuchseiten.
<li>OpenBSD benötigt KEIN <code>-lcrypt</code>.<br>
DES ist Teil der Standard-<code>libc</code>.
<li>OpenBSD hat einen separaten Namensraum für User und Gruppen,
die von Portierungen erzeugt werden.
Siehe <code>/usr/ports/infrastructure/db/user.list</code> für
genaue Details.
<li>OpenBSD is stark sicherheitsorientiert. Du solltest die
<a href="#Security">Sicherheitssektion</a> auf dieser Seite
lesen und verstehen.
<li>Stelle sicher, dass der <code>$OpenBSD$</code>-CVS-Tag
in das Makefile eingefügt wird. Wenn du eine Portierung von einem
anderen System importierst, stelle sicher, dass du auch ihren
Tag in dem Makefile belässt.
<li>Das Ziel ist, dass alle portierten Anwendungen OpenBSD
unterstützen. Um dieses Ziel zu erreichen,
<strong>musst</strong> du alle OpenBSD-Korrekturroutinen auch zurück an
den ursprünglichen Programmierer zurückliefern.
</ul>
<h3><font color="#0000e0"><a name="Security">Sicherheitsempfehlungen</a></font></h3>
Es gibt viele Sicherheitsprobleme, über die man sich Gedanken machen
muss. Wenn du nicht absolut sicher bist, was du tust, frage
bitte auf der
<a href="mailto:[email protected]">Portierungs</a>-Mailingliste um
Hilfe.
<ul>
<li>Benutze <em>keinen</em> Alpha- oder Beta-Code, wenn du eine
Portierung vorbereitest.
Benutze die letzte reguläre Version oder die zuletzt korrigierte.
<li>Jegliche Software, die auf einem Server installiert werden soll,
sollte auf Pufferüberläufe (buffer overflows) untersucht werden,
insbesondere unsichere Benutzung von
<code>strcat/strcpy/strcmp/sprintf</code>. Im Allgemeinen sollte
<code>sprintf</code> durch <code>snprintf</code> ersetzt werden.
<li>Benutze niemals Dateinamen statt echter Sicherheit. Es gibt
zahlreiche Wettlaufsituationen, in denen du keine saubere
Kontrolle mehr hast. Ein Angreifer, der bereits normale
Benutzerrechte auf deiner Maschine hat, könnte Dateien in
<code>/tmp</code> mit symbolischen Links auf strategischere
Dateien setzen, wie etwa <code>/etc/master.passwd</code>.
<li>Zum Beispiel erzeugen sowohl <code>fopen</code> als auch
<code>freopen</code>
<strong>eine neue Datei oder öffnen eine bereits
existierende</strong> zum Schreiben. Ein Angreifer könnte einen
symbolischen Link von <code>/etc/master.passwd</code> auf
<code>/tmp/addrpool_dump</code> setzen. Sofort wenn du ihn
öffnest ist deine Passwortdatei verraten. Ja, sogar mit einem
<code>unlink</code> direkt davor. Du kannst nur die Anzahl der
Möglichkeiten verringern. Benutze stattdessen
<code>open</code> mit <code>O_CREAT|O_EXCL</code> und
<code>fdopen</code>.
<li>Ein weiteres sehr bekanntes Problem ist die
<code>mktemp</code>-Funktion. Beachte die Warnungen des
,bsd linker's bei ihrer Benutzung.
<strong>Die müssen gefixt werden</strong>. Das ist nicht ganz
so einfach wie <code>s/mktemp/mkstemp/g</code>. <br>
Sieh dir
<a href="http://www.openbsd.org/cgi-bin/man.cgi?sektion=3&query=mktemp"
><code>mktemp(3)</code></a> genauer an, um weitere Informationen
zu erhalten.
Korrekter Code, der <code>mkstemp</code> benutzt, schließt den
Source zu <code>ed</code> oder <code>mail</code> ein.
Eine seltenes Beispiel an Code, der <code>mktemp</code> korrekt
benutzt, kann in der <code>rsync</code>-Portierung gefunden werden.
<li>Nur weil du etwas lesen kannst heißt es nicht, dass du das
solltest. Eine sehr bekannte Lücke dieser Art war das
<code>startx</code>-Problem. Als setuid-Programm konntest du
startx mit jeder Datei als Skript starten. Wenn die Datei kein
sauberes Shellskript war, folgte eine Fehlermeldung zusammen mit
der ersten Zeile der betreffenden Datei, ohne weitere Überprüfung
der Rechte. Ziemlich einfach die erste Zeile der
shadow-passwd-Datei zu erhalten, besonders wenn man bedenkt, dass
die erste Zeile meist den root-Eintrag enthält.
Öffne nicht deine Datei, um dann ein <code>fstat</code> auf den
,open descriptor' zu machen, um zu überprüfen, ob du sie hättest
öffnen können müssen (oder der Angreifer wird mit /dev/rst0
spielen und dein Band zurückspulen) - öffne es mit korrekt
gesetzter uid/gid/grouplist.
<li>Tue nichts, was eine Shell im Hintergrund von setuid-Programmen
forkt bevor du deine Rechte zurücksetzt. Das schließt
<code>popen</code> und
<code>system</code> ein.
Benutze stattdessen <code>fork</code>, <code>pipe</code> und
<code>execve</code>.
<li>
Gebe ,open descriptors' anstatt von Dateiname an andere Programme
weiter, um Wettlaufsituationen zu vermeiden. Sogar wenn ein
Programm keine 'file descriptors' akzeptiert, kannst du immer noch
<code>/dev/fd/0</code> benutzen.
<li>Zugriffsrechte sind an ,file descriptors' gebunden. Wenn du
setuid-Rechte setzen musst, um eine Datei zu öffnen, öffne die
Datei, dann lass deine Rechte fallen. Du kannst nach wie vor auf
den ,open descriptor' zugreifen, aber du musst dir um ihn weniger
Sorgen machen. Das hat aber zwei Seiten: auch nachdem du die
Rechte fallen lassen hast, solltest du noch auf die ,descriptors'
aufpassen.
<li>Vermeide root-setuid wo du nur kannst. Grundsätzlich kann root
alles tun, aber root-Rechte werden nur sehr selten wirklich
benötigt, vielleicht mit Ausnahme vom Erzeugen von Sockets mit
einer Nummer kleiner 1024. Es ist beutend besser, das
<code>inetd</code> zu überlassen und nur die relevanten Einträge
in <code>inetd.conf</code> zu machen. Du musst selbstverständlich
die erforderliche Magie zum Schreiben von Daemons kennen, um das
zu erreichen. Man könnte sagen, dass du keinerlei Chancen hast,
ein gutes setuid-Programm zu schreiben, wenn du nicht weißt, wie
man das macht.
<li>Benutze setgid anstelle von setuid. Abgesehen von diesen
bestimmten Dateien, die von setgid-Programmen benötigt werden,
sind die meisten Dateien nicht ,group-writable'. Daher werden
Sicherheitsprobleme in einem setgid-Programm dein System nicht
bedrohen: nur mit Gruppenrechten wird das schlimmste, was ein
Angreifer anrichten kann, das Hacken einer Score-Tabelle in einem
Spiel oder etwas ähnliches sein. Siehe auch die
<code>xkobo</code>-Portierung für ein Beispiel einer solchen Änderung.
<li>Vertraue keinen ,group-writable' Dateien. Auch wenn sie geprüft
wurden, werden setgid immer noch als wichtige potenzielle
Sicherheitslöcher betrachtet. Von daher sollten Informationen,
die hiervon berührt werden nicht als sensitive Information
betrachtet werden.
<li>Vertraue nicht deiner Umgebung! Das schließt einfache Dinge wie
etwa deinen <code>PATH</code> ein (benutze niemals
<code>system</code> mit einem unqualifizierten Namen, vermeide
<code>execvp</code>), es betrifft aber auch solche feinen Dinge
wie locale, timezone, termcap, und so weiter. Sei vorsichtig mit
,transitivity': Auch wenn du alle Vorsichtsmaßregeln triffst,
machen das Programme, die du aufrufst, noch lange nicht.
Benutze <strong>niemals</strong> <code>system</code> in
privilegierten Programmen, baue eine saubere Kommandozeile,
eine kontrollierte Umgebung und rufe <code>execve</code> direkt
auf. Die <code>perlsec</code>-Handbuchseite ist ein gutes Tutorium
über solche Probleme.
<li>Benutze niemals setuid-Shellskripte. Sie sind vererbliche
Sicherheitslücken. Schließe sie in C-Code ein, der eine saubere
Umgebung sicherstellt. Auf der anderen Seite gibt es unter
OpenBSD auch die sicheren Perl-Skripte.
<li>Nimm dich vor dem ,dynamic loader' in Acht. Wenn du ihn mit
setuid laufen lässt, wird er nur vertrauenswürdigen Bibliotheken
trauen, die mit ldconfig gescannt wurden. Setgid ist nicht genug.
<li>Dynamische Bibliotheken sind schwierig. C++-Code stellt ein
ähnliches Problem dar. Grundsätzlich könnten Bibliotheken einige
Dinge basierend auf deiner Umgebung tun, sogar bevor dein
Hauptprogramm dazu kommt, seinen setuid-Status zu checken.
OpenBSD-<code>issetugid</code> kümmert sich um dieses Problem
vom Standpunkt eines-Bibliotheks-Autors aus. Versuche nicht
Bibliotheken zu portieren, bis du diesen Punkt wirklich
absolut verstanden hast.
</ul>
<h3><font color="#0000e0"><a name="Generic">Allgemeine Portierungshinweise</a></font></h3>
<ul>
<li><code>__OpenBSD__</code> sollte sparsam benutzt werden, wenn
überhaupt. Konstruktionen, die wie
<pre>
#if defined(__NetBSD__) || defined(__FreeBSD__)
</pre>
aussehen, sind oft unpassend. Füge nicht blindlings
<code>__OpenBSD__</code> hinzu. Versuche stattdessen
herauszufinden, was vor sich geht und welche Funktionalität
tatsächlich gebraucht wird. Handbuchseiten sind oftmals hilfreich,
da sie historische Kommentare enthalten und darstellen, wann eine
spezielle Funktionalität in OpenBSD eingefügt wurde. Den
numerischen Wert von <code>BSD</code> gegen bekannte
Versionen/Zahlen zu prüfen ist meistens der richtige Weg. Der
<a href="http://www.netbsd.org/Documentation/pkgsrc/">NetBSD
pkgsrc guide</a>
enthält noch weitere Informationen.
<li><code>BSD</code> zu definieren ist eine schlechte Idee. Versuche
<code>sys/param.h</code> einzubinden. Das definiert nicht nur
<code>BSD</code>, sondern gibt auch einen sauberen Wert.
Das richtige Codefragment sollte etwa so aussehen:
<pre>
#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endif
</pre>
<li>Teste, ob Funktionalitäten vorhanden sind, und nicht nach
bestimmten Betriebssystemen. Auf lange Sicht ist es besser zu
erfahren, ob <code>tcgetattr</code> funktioniert, als zu
erfahren, ob man gerade auf 4.3 BSD oder später oder etwa
SystemVR4 arbeitet. Diese Art von Test trifft einfach nicht den
Punkt. Ein sinnvoller Weg wäre zum Beispiel auf ein bestimmtes
System zu testen, eine Runde von <code>HAVE_TCGETATTR</code> zu
definieren und dann mit dem nächsten System weiterzumachen.
Diese Technik trennt die Funktionalitätstests von denen auf
spezielle Betriebssysteme. In großer Eile kann ein anderer
Portierer das ganze Set an <code>-DHAVE_XXX</code>-Definitionen
zum Makefile hinzufügen. Man könnte das auch selber schreiben
oder im configure-Skript testen und es dann automatisch
hinzufügen. Als negatives Beispiel, dem man _nicht_ folgen
sollte, kann der nethack-3.2.2-Source dienen: er nimmt jede
Menge Dinge basierend auf dem Systemtyp an. Die meisten dieser
Annahmen sind veraltet und haben nichts mehr mit der Realität zu
tun: POSIX sind nützlicher als alte
BSD-versus-SystemV-Unterschiede, da einige traditionelle
BSD-Funktionen jetzt nur noch durch
Kompatibilitäts-Bibliotheken unterstützt werden.
<li>Vermeide include-Dateien, die andere includes enthalten, die
wiederum andere ... Erstens weil es ineffizient ist. Dein Projekt
wird mit einer Datei enden, die alles andere ,included'. Und
außerdem werden dabei Probleme erzeugt, die schwierig zu beheben
sind. Es wird schwieriger an einem bestimmten Punkt
<em>nicht</em> eine bestimmte Datei mit einzubinden.
<li>Vermeide bizarre macro-Tricks. 'Undefining' eines Makros, das von
einer Header-Datei definiert wurde, ist eine schlechte Idee. Das
Definieren eines Makros, um ein spezielles Verhalten von einer
include-Datei zu bekommen, ist auch eine schlechte Idee:
Kompiliermodi sollten global sein. Wenn du POSIX-Verhalten willst,
teile es mit, indem du <code>#define POSIX_C_SOURCE</code> im
ganzen Projekt einsetzt, nicht nur wenn dir danach ist.
<li>Schreibe niemals ,system function prototypes'. Alle modernen
Systeme, inklusive OpenBSD, haben einen Standardplatz für diese
,prototypes'. Wahrscheinliche Plätze sind etwa
<code>unistd.h</code>, <code>fcntl.h</code> oder
<code>termios.h</code>. Die Handbuchseite zeigt regelmäßig wo die
,prototypes' zu finden sind. Du könntest noch eine Runde
<code>HAVE_XXX</code>-Makros benötigen, um die richtige Datei zu
beschaffen. Mach dir keine Sorgen darum , dass du eine Datei
zweimal 'includen' könntest, include Dateien haben Aufpasser, die
solchen Unfug verhindern.<br>
Falls irgendein kaputtes System von dir verlangt, den ,prototype'
zu schreiben, dehne das nicht gleich auf alle anderen Systeme
aus. ,Roll-your-own prototypes' werden nicht funktionieren, da
sie Typen benutzen könnten, die auf deinem System funktionieren,
aber eben nicht auf andere Systeme portierbar sind;
(<code>unsigned long</code> anstelle von <code>size_t</code>)
benutzen, oder einen <code>const</code>-Status falsch verstehen.
Außerdem sind einige Compiler, so wie auch OpenBSDs gcc,
in der Lage, bessere Arbeit mit sehr oft verwendeten Funktionen
wie <code>strlen</code> zu leisten, wenn man die richtigen
header-Dateien einbindet.
<li>Untersuche das ,build log' sorgfältig auf Compiler-Warnungen.
<ul><li>
<code>implicit declaration of function foo()</code>
bedeutet, dass ein Funktionsprototyp nicht vorhanden ist.
Das bedeutet, dass der Compiler annimmt, dass der Typ
des Rückgabewert Integer ist.
Gibt die Funktion eigentlich einen Pointer zurück,
wird dieser auf 64-Bit-Systemen abgeschnitten, was
üblicherweiße zu einem Segmentation-Fault führt.
</ul>
<li>Benutze nicht den Namen einer Standard-Systemfunktion für
irgendetwas anderes. Wenn du deine eigene Funktion schreiben
willst, gib ihr einen eigenen Namen und rufe diese Funktion
überall auf. Wenn du zur Standard-Systemfunktion zurückkehren
willst, musst du nur deinen Code auskommentieren und den Namen
wieder auf die Systemfunktion zurückschreiben. Mach es nicht
andersherum. Der Code sollte etwa so aussehen:
<pre>
/* ,prototype'-Teil */
#ifdef USE_OWN_GCVT
char *foo_gcvt(double number, size_t ndigit, char *buf);
#else
/* die richtige Datei einbinden */
#include <stdlib.h>
/* use system function */
#define foo_gcvt gcvt
#endif
/* ,definition'-Teil */
#ifdef USE_OWN_GCVT
char *foo_gcvt(double number, size_t ndigit, char *buf)
{
/* proper definition */
}
/* typische Verwendung */
s = foo_gcvt(n, 15, b);
</pre>
</ul>
<h3><font color="#0000e0"><a name="Other">Andere hilfreiche Hinweise</a></font></h3>
<ul>
<li>Neuere Versionen von <code>bsd.port.mk</code> setzen den
Installer-Pfad. Sie sorgen insbesondere dafür, dass
<code>/usr/bin</code> und <code>/bin</code> <em>vor</em>
<code>/usr/local/bin</code> und <code>/usr/X11R6/bin</code>
durchsucht werden.
<li>Erzeuge <em>KEINE</em> Shared Librarys wenn
<code>${NO_SHARED_LIBS}</code> auf YES gesetzt ist (Vorsicht: es
kann nur nach der Einbindung von <code>bsd.port.mk</code>
definiert werden). Wenn deine Portierung ein
GNU-configure benutzt, füge einfach die Zeile
<code>CONFIGURE_ARGS += ${CONFIGURE_SHARED}</code> in das
Makefile ein.
<li>Es ist in Ordnung eine erst neulich hinzugefügte Funktionalität
von <code>bsd.port.mk</code> zwingend zu benötigen, da die Leute
sowieso ihren Portierungsbaum mitsamt <code>bsd.port.mk</code>
updaten sollten. NEED_VERSION ist von nun an hinfällig.
<li>Bevorzuge <code>update-plist</code>, um Paketlisten zu generieren
und zu aktualisieren, anstatt diese Dinge per Hand zu erledigen.
Du kannst die unerwünschten Zeilen auskommentieren.
<code>update-plist</code> kann die meisten Dateitypen alleine
erkennen und die meisten zusätzlichen ,annotations' korrekt
kopieren.
<li>Füge <code>USE_SYSTRACE=Yes</code> in <code>/etc/mk.conf</code>
ein, um fehlfunktionierende Skripte, Makefiles etc. zu
entdecken.
<li>In OpenBSD sind <code>curses.h/libcurses/libtermlib</code> die
,neuen curses'. Ändere:<br>
<code>ncurses.h ==> curses.h</code><br>
,old (BSD) curses' ist durch das Definieren von
<code>_USE_OLD_CURSES_</code> verfügbar
und zwar vor dem Einbinden von <code>curses.h</code> (für
gewöhnlich in einem Makefile) und dem Linken mit
<code>-locurses</code>.
<li>In OpenBSD wurden die Terminals von den alten
BSD-<code>sgtty</code> zur neuen
POSIX-<code>tcgetattr</code>-Familie umgestellt. Vermeide den
alten Stil in neuem Code. Es kann Code geben, der
<code>tcgetattr</code> als Synonym für das ältere
<code>sgtty</code> definiert, aber das ist auf OpenBSD höchstens
eine kurzfristige Methode.
Der <code>xterm</code>-Quelltext ist ein sehr gutes Beispiel,
wie man es nicht machen sollte. Versuche deine
Systemfunktionalität richtig hinzubekommen: Du
willst ja einen Typen, der den Status deines Terminals behält
(möglicher typedef), du willst eine Funktion, die den momentanen
Status herausfindet, und eine Funktion, die den neuen Status
setzt. Funktionen, die diesen Status modifizieren sind
schwieriger als es den Anschein hat, da sie dazu tendieren, von
System zu System unterschiedlich zu sein. Vergiss auch
nicht, dass du Fälle behandeln musst, bei denen du gar nicht an
einem Terminal angeschlossen bist, und in denen du ,signals'
behandeln musst: nicht nur das Beenden, sondern auch
(<code>SIGTSTP</code>) im Hintergrund. Du solltest das Terminal
immer in einem sauberen Zustand belassen. Mach die Tests unter
einer alten Shell, wie etwa sh, die das Terminal nicht gleich in
allen Fällen zurücksetzt, nachdem das Programm beendet wurde.
<li>Die neueren termcap/terminfo und curses, wie sie Teil von
OpenBSD sind, beinhalten Standardsequenzen für das Kontrollieren
von Farb-Terminals. Wenn möglich benutze diese, kehre auf
anderen Systemen auf die ANSI-Farbsequenzen zurück. Trotzdem
sind noch nicht alle Terminalbeschreibungen auf dem neuesten
Stand, und du musst möglicherweise in der Lage sein, diese
Sequenzen von Hand zu bearbeiten. So macht es vim. Das ist aber
nicht unbedingt notwendig. Mit Ausnahme von privilegierten
Programmen ist es generell möglich, eine termcap-Definition
durch die <code>TERMCAP</code>-Variable zu übersteuern
und sie dadurch zu sauberem Arbeiten zu bringen.
<li>Signal-Semantiken sind schwierig und von System zu System
verschieden.
Benutze <code>sigaction</code>, um spezifische Semantiken zu
bekommen, zusammen mit anderen Systemaufrufen, die in der
entsprechenden Handbuchseite aufgeführt werden.
</ul>
<hr>
<a href="index.html"><img height=24 width=24 src=../back.gif border=0 alt=OpenBSD></a>
<a href="mailto:[email protected]">[email protected]</a>
<br><small>
<!--
Originally [OpenBSD: porting.html,v 1.59 ]<br>
$Translation: porting.html,v 1.57 2012/04/19 17:46:12 steffen Exp $<br>
-->
$OpenBSD: porting.html,v 1.54 2012/04/19 23:56:50 ajacoutot Exp $
</small>
</body>
</html>