summaryrefslogtreecommitdiff
path: root/service_solahart_jakarta_selatan__082122541663/glibc.mdwn
blob: c932e45bd769495e4ebae1ee5c1b222e57fcd86c (plain)
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
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013, 2014 Free
Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_glibc]]

Here's what's to be done for maintaining glibc.

[[!toc levels=2]]


# [[General information|/glibc]]

  * [[service_solahart_jakarta_selatan__082122541663/Versioning]]


# [[Sources|source_repositories/glibc]]


# [[Debian Cheat Sheet|debian]]


# Configuration

<!--

git checkout reviewed
git log --reverse --topo-order --pretty=fuller --stat=$COLUMNS,$COLUMNS -b -p -C --cc ..sourceware/master
-i
/^commit |^merge:|^---$|mach[^i]|hurd|linux|gs:|__assume

-->

Last reviewed up to the [[Git mirror's 64a17f1adde4715bb6607f64decd73b2df9e6852
(2013-12-19) sources|source_repositories/glibc]].

  * <a id=t_hurdsig-fixes>`t/hurdsig-fixes`</a>

        hurdsig.c: In function '_hurd_internal_post_signal':
        hurdsig.c:1188:26: warning: 'pending' may be used uninitialized in this function [-Wmaybe-uninitialized]
        hurdsig.c:1168:12: note: 'pending' was declared here

  * <a id=t_host-independency>`t/host-independency`</a>

    [[!message-id "87bougerfb.fsf@kepler.schwinge.homeip.net"]], [[!message-id
    "20120525202732.GA31088@intel.com"]], commit
    918b56067a444572f1c71b02f18255ae4540b043.  [[!GCC_PR 53183]], GCC commit
    c05436a7e361b8040ee899266e15bea817212c37.

  * <a id=t_pie-sbrk>`t/pie-sbrk`</a>

    [[service_solahart_jakarta_selatan__082122541663/gcc/Pie]].

  * <a id=t_sysvshm>`t/sysvshm`</a>

        ../sysdeps/mach/hurd/shmat.c: In function '__shmat':
        ../sysdeps/mach/hurd/shmat.c:57:7: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration]
        ../sysdeps/mach/hurd/shmget.c: In function 'get_exclusive':
        ../sysdeps/mach/hurd/shmget.c:85:8: warning: variable 'is_private' set but not used [-Wunused-but-set-variable]
        ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'dir' may be used uninitialized in this function [-Wmaybe-uninitialized]
        ../sysdeps/mach/hurd/shmget.c:102:8: warning: 'file' may be used uninitialized in this function [-Wmaybe-uninitialized]

  * <a id=t_tls>[[`t/tls`|service_solahart_jakarta_selatan__082122541663/glibc/t/tls]]</a>

  * <a id=t_tls-threadvar>[[`t/tls-threadvar`|service_solahart_jakarta_selatan__082122541663/glibc/t/tls-threadvar]]</a>

  * <a id=t_verify.h>`t/verify.h`</a>

    People didn't like this too much.

    Other examples:

      * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- `static_assert`

  * <a id=toolchain_cross-gnu>[[toolchain/cross-gnu]], without `--disable-multi-arch`</a>

        i686-pc-gnu-gcc ../sysdeps/i386/i686/multiarch/strcmp.S -c [...]
        ../sysdeps/i386/i686/multiarch/../strcmp.S: Assembler messages:
        ../sysdeps/i386/i686/multiarch/../strcmp.S:31: Error: symbol `strcmp' is already defined
        make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/string/strcmp.o] Error 1
        make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/string'

    Might simply be a missing patch(es) from master.

  * <a id=disable-multi-arch>`--disable-multi-arch`</a>

    IRC, freenode, #hurd, 2012-11-22

        <pinotree> tschwinge: is your glibc build w/ or w/o multiarch?
        <tschwinge> pinotree: See open_issues/glibc: --disable-multi-arch
        <pinotree> ah, because you do cross-compilation?
        <tschwinge> No, that's natively.
        <tschwinge> There is also a not of what happened in cross-gnu when I
          enabled multi-arch.
        <tschwinge> No idea whether that's still relevant, though.
        <pinotree> EPARSE
        <tschwinge> s%not%note
        <tschwinge> Better?
        <pinotree> yes :)
        <tschwinge> As for native builds: I guess I just didn't (want to) play
          with it yet.
        <pinotree> it is enabled in debian since quite some time, maybe other
          i386/i686 patches (done for linux) help us too
        <tschwinge> I though we first needed some CPU identification
          infrastructe before it can really work?
        <tschwinge> I thought [...].
        <pinotree> as in use the i686 variant as runtime automatically? i guess
          so
        <tschwinge> I thought I had some notes about that, but can't currently
          find them.
        <tschwinge> Ah, I probably have been thinking about open_issues/ifunc
          and open_issues/libc_variant_selection.

  * <a id=buildX>--build=X</a>

    `long double` test: due to `cross_compiling = maybe` wants to execute a
    file, which fails.  Thus `--build=X` has to be set.

  * <a id=check>Check what all these are:</a>

        running configure fragment for sysdeps/mach/hurd
        checking Hurd header version... ok
        running configure fragment for sysdeps/mach
        checking for i586-pc-gnu-mig... i586-pc-gnu-mig
        checking for mach/mach_types.h... yes
        checking for mach/mach_types.defs... yes
        checking for task_t in mach/mach_types.h... task_t
        checking for thread_t in mach/mach_types.h... thread_t
        checking for creation_time in task_basic_info... yes
        checking for mach/mach.defs... yes
        checking for mach/mach4.defs... yes
        checking for mach/clock.defs... no
        checking for mach/clock_priv.defs... no
        checking for mach/host_priv.defs... no
        checking for mach/host_security.defs... no
        checking for mach/ledger.defs... no
        checking for mach/lock_set.defs... no
        checking for mach/processor.defs... no
        checking for mach/processor_set.defs... no
        checking for mach/task.defs... no
        checking for mach/thread_act.defs... no
        checking for mach/vm_map.defs... no
        checking for mach/memory_object.defs... yes
        checking for mach/memory_object_default.defs... yes
        checking for mach/default_pager.defs... yes
        checking for mach/i386/mach_i386.defs... yes
        checking for egrep... grep -E
        checking for host_page_size in mach_host.defs... no
        checking for mach/machine/ndr_def.h... no
        checking for machine/ndr_def.h... no
        checking for i386_io_perm_modify in mach_i386.defs... yes
        checking for i386_set_gdt in mach_i386.defs... yes
        checking whether i586-pc-gnu-mig supports the retcode keyword... yes

  * <a id=stackguard>`sysdeps/i386/stackguard-macros.h`</a>

    See [[t/tls|service_solahart_jakarta_selatan__082122541663/glibc/t/tls]].

  * <a id=77c84aeb81808c3109665949448dba59965c391e>Verify 77c84aeb81808c3109665949448dba59965c391e against
    `~/shared/glibc/make_TAGS.patch`.</a>

  * <a id=HP_SMALL_TIMING_AVAIL>`HP_SMALL_TIMING_AVAIL` not defined anywhere.</a>

  * <a id=CPUCLOCK_WHICH>Unify `CPUCLOCK_WHICH` stuff in `clock_*` files.</a>

  * <a id=tests-clean>Not all tests are re-run in a `make -k tests; make tests-clean; make -k
    tests` cycle.  For example, after `make tests-clean`:</a>

        $ find ./ -name \*.out
        ./localedata/tst-locale.out
        ./localedata/sort-test.out
        ./localedata/de_DE.out
        ./localedata/en_US.out
        ./localedata/da_DK.out
        ./localedata/hr_HR.out
        ./localedata/sv_SE.out
        ./localedata/tr_TR.out
        ./localedata/fr_FR.out
        ./localedata/si_LK.out
        ./localedata/tst-mbswcs.out
        ./iconvdata/iconv-test.out
        ./iconvdata/tst-tables.out
        ./stdlib/isomac.out
        ./posix/wordexp-tst.out
        ./posix/annexc.out
        ./posix/tst-getconf.out
        ./elf/check-textrel.out
        ./elf/check-execstack.out
        ./elf/check-localplt.out
        ./c++-types-check.out
        ./check-local-headers.out
        ./begin-end-check.out

  * <a id=t_cpuclock>`CPUCLOCK_WHICH`, `t/cpuclock`</a>

        /media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt_pic.a(clock_settime.os): In function `clock_settime':
        /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:113: undefined reference to `CPUCLOCK_WHICH'
        /media/boole-data/thomas/tmp/gnu-0/src/glibc/rt/../sysdeps/unix/clock_settime.c:114: undefined reference to `CPUCLOCK_WHICH'
        collect2: error: ld returned 1 exit status
        make[2]: *** [/media/boole-data/thomas/tmp/gnu-0/src/glibc.obj/rt/librt.so] Error 1
        make[2]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc/rt'
        make[1]: *** [rt/others] Error 2
        make[1]: Leaving directory `/media/boole-data/thomas/tmp/gnu-0/src/glibc'
        make: *** [all] Error 2

  * <a id=missing>Missing Interfaces</a>

    We have posted a [[Google Summer of Code project proposal|community/gsoc]]:

    [[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no
    actions=yes]]

    Many are missing for GNU Hurd, some of which have been announced in
    [`NEWS`](https://sourceware.org/git/?p=glibc.git;a=blob;f=NEWS), others
    typically haven't (like new flags to existing functions).  Typically,
    porters will notice missing functionaly.  But in case you're looking for
    something to work on, here's a bit of a commented list, otherwise go
    looking in `/usr/include/i386-gnu/gnu/stubs.h` on a Debian GNU/Hurd system,
    or the respective file from a fresh glibc build.

    `AT_EMPTY_PATH`, `CLOCK_BOOTTIME`, `CLOCK_BOOTTIME_ALARM`,
    `CLOCK_REALTIME_ALARM`, `O_PATH`, `O_TMPFILE`
    (ffdd31816a67f48697ea4d6b852e58d2886d42ca),
    `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27,
    b1b2aaf8eb9eed301ea8f65b96844568ca017f8b,
    521c6785e1fc94d1f501743e9a40af9e02797df3),
    `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`)
    `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`,
    `open_by_handle_at`,
    `posix_openpt`, `process_vm_readv`, `process_vm_writev`,
    `setns`, `sync_file_range`, [[`mremap`|mremap]] and [[several
    `MAP_*`|glibc/mmap]]

    Check also the content of `gnu/stubs.h`, which lists all the functions
    marked as stub which only return `ENOSYS`.

      * <a id=chflags>`chflags`</a>

        Patch sent, [[!message-id "20120427012130.GZ19431@type.famille.thibault.fr"]].

        IRC, OFTC, #debian-hurd, 2012-04-27:

            <Steap> Does anyone have any idea why int main(void) { return
              chflags(); } will compile with gcc but not with g++ ? It says
              that "chflags" was not declared in this scope.
            <Steap> I get the same error on FreeBSD, but including sys/stat.h
              makes it work
            <Steap> Can't find a solution on Hurd though :/
            <youpi> the Hurd doesn't have chflags
            <youpi> apparently linux neither
            <youpi> what does it do?
            <Steap> change flags :)
            <Steap> Are you sure the Hurd does not have chflags ? Because gcc
              does not complain
            <youpi> there is no chflags function in /usr/include
            <youpi> but what flags does it change?
            <Steap> According to the FreeBSD manpage, it can set flags such as
              UF_NODUMP, UF_IMMUTABLE etc.
            <youpi> Hum, there is actually a chflags() definition
            <youpi> but no declaration
            <youpi> so actually chflags is supported, but the declaration was
              forgotten
            <youpi> probably because since linux doens't have it, it has never
              been a problem up to now
            <youpi> so I'd say ignore the error for now, we'll add the
              declaration

      * <a id=t_tls-threadvar>[[service_solahart_jakarta_selatan__082122541663/glibc/t/tls-threadvar]]</a>

      * <a id=futimesat>`futimesat`</a>

        If we have all of 'em (check Linux kernel), `#define __ASSUME_ATFCTS`.

      * `futimens`

        IRC, freenode, #hurd, 2014-02-09:

            <youpi> it seems apt 0.9.15.1 has troubles downloading packages
              etc., as opposed to apt 0.9.15
            <youpi> ah, that version uses futimens unconditionally
            <youpi> and we haven't implemented that yet
            <azeem> did somebody file a bug for that apt-get issue?
            <youpi> I haven't
            <youpi> I'll commit the fix in eglibc
            <youpi> but perhaps a bug report would be good for the kfreebsd
              case

      * <a id=bits_stat.h>`bits/stat.h [__USE_ATFILE]`: `UTIME_NOW`, `UTIME_OMIT`</a>

      * <a id=__USE_ATFILE>`io/fcntl.h [__USE_ATFILE]`</a>

        Do we support `AT_FDCWD` et al.?
        (80b4e5f3ef231702b24d44c33e8dceb70abb3a06.)

      * <a id=t_opendirat>`t/opendirat`: `opendirat` (`scandirat`, `scandirat64`)</a>

        Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 +
        14d96785125abee5e9a49a1c3037f35a581750bd.

      * <a id=madvise>`madvise`, `MADV_DONTNEED`, `MADV_DONTDUMP`, `MADV_DODUMP`</a>

        [[glibc_madvise_vs_static_linking]].

        IRC, OFTC, #debian-hurd, 2013-09-09:

            <gg0> does hurd MADV_DONTNEED or MADV_FREE or none?
              http://sources.debian.net/src/jemalloc/3.4.0-1/include/jemalloc/jemalloc_defs.h.in#L239
            <gg0> seems it builds by defining JEMALLOC_PURGE_MADVISE_DONTNEED
              but i don't know what i'm talking about, so it could build with
              JEMALLOC_PURGE_MADVISE_FREE as well

        IRC, OFTC, #debian-hurd, 2013-09-10:

            <youpi> gg0: it implements none, even if it defines DONTNEED (but
              not FREE)

        See also:

            gnash (0.8.11~git20130903-1) unstable; urgency=low
            
              * Git snapshot.
                + Embedded jemalloc copy has been replaced by system one.
                  [...]
                  - Disable jemalloc on hurd and kfreebsd-*. No longer disabled upstream.

      * <a id=msync>`msync`</a>

        Then define `_POSIX_MAPPED_FILES`, `_POSIX_SYNCHRONIZED_IO`.

      * <a id=epoll>`epoll`, `sys/epoll.h`</a>

        Used by [[wayland]], for example.

        IRC, freenode, #hurd, 2013-08-08:

            <nalaginrut> is there any possible to have kquque/epoll alike
              things in hurd? or there is one?
            <braunr> nalaginrut: use select/poll
            <nalaginrut> is it possible to implement epoll?
            <braunr> it is
            <braunr> we don't care enough about it to do it
            <braunr> (for now)
            <nalaginrut> well, since I wrote a server with Guile, and it could
              take advantage of epoll, never mind, if there's no, it'll use
              select automatically
            <nalaginrut> but if someday someone care about it, I'll be
              interested on it
            <braunr> epoll is a scalability improvement over poll
            <braunr> the hurd being full of scalability issues, this one is
              clearly not a priority
            <nalaginrut> ok

        IRC, freenode, #hurd, 2013-09-26:

            <nalaginrut> if I want to have epoll/kqueue like things, where
              should it dwell? kernel or some libs?
            <braunr> libs
            <pinotree> userland
            <braunr> that would be a good project to work on, something i
              intended to do (so i can help) but it requires a lot of work
            <braunr> you basically need to add a way to explicitely install and
              remove polling requests (instead of the currently way that
              implicitely remove polling requests when select/poll returns)
            <braunr> while keeping the existing way working for some time
            <braunr> glibc implements select
            <braunr> the hurd io interface shows the select interface
            <braunr> servers such as pfinet/pflocal implement it
            <braunr> glibc implements the client-side of the call
            <nalaginrut> where's poll? since epoll just added edge-trigger in
              poll
            <braunr> both select and poll are implemented on top of the hurd io
              select call (which isn't exactly select)
            <braunr>
              http://darnassus.sceen.net/gitweb/savannah_mirror/hurd.git/blob/HEAD:/hurd/io.defs
            <braunr> this is the io interface
            <braunr>
              http://darnassus.sceen.net/gitweb/savannah_mirror/glibc.git/blob/refs/heads/tschwinge/Roger_Whittaker:/hurd/hurdselect.c
            <braunr> this is the client side implementation

        IRC, freenode, #hurd, 2014-02-14:

            <desrt> also: do you know if hurd has a modern-day poll()
              replacement? ala epoll, kqueue, iocp, port_create(), etc?
            <pochu_> last thing I remember was that there was no epoll
              equivalent, but that was a few years ago :)
            <pochu_> braunr: ^
            * desrt is about to replace gmaincontext in glib with something
                more modern
            * desrt really very much wants not to have to write a poll()
                backend....
            <desrt> it seems that absolutely every system that i care about,
              except for hurd, has a new approach here :/
            <desrt> even illumos has solaris-style ports
            <azeem> desrt: I suggest you bring up the question on bug-hurd
            <azeem> the poll() system call there to satisfy POSIX, but there
              might be a better Hurd-specific thing you could use
            <azeem> is there*
            <desrt> that would be ideal
            <desrt> i have to assume that a system that passes to many messages
              has some other facilities :)
            <desrt> *so many
            <desrt> the question is if they work with fds....
            <desrt> bug-hurd doesn't seem like a good place to ask open-ended
              questions....
            <azeem> it's the main development lists, it's just old GNU naming
            <azeem> list*
            <desrt> k.  thanks.
            <azeem> bug-hurd@gnu.org is the address
            * desrt goes to bug... hurd
            <desrt> written.  thanks.
            <braunr> desrt: the hurd has only select/poll
            <braunr> it suffers from so many scalability issues there isn't
              much point providing one currently
            <braunr> we focus more on bug fixing and posix compliance right now
            <desrt> fair answer
            <braunr> you should want a poll-based backend
            <braunr> it's the most portable one, and doesn't suck as much as
              select
            <braunr> very easy to write
            <braunr> although, internally, our select/poll works just like a
              bare epoll
            <braunr> i.e. select requests are installed, the client waits for
              one or more messages, then uninstalls the requests

        IRC, freenode, #hurd, 2014-02-23:

            <desrt> brings me to another question i asked here recently that
              nobody had a great answer for: any plan to do kqueue?
            <braunr> not for now
            <braunr> i remember answering you about that
            <desrt> ah.  on IRC or the list?
            <braunr> that internally, our select/poll implementation works just
              like epoll
            <braunr> on irc
            <braunr> well "just like" is a bit far from the truth
            <desrt> well... poll() doesn't really work like epoll :p
            <braunr> internally, it does
            <braunr> even on linux
            <desrt> since both of us have to do the linear scan on the list
            <desrt> which is really the entire difference
            <braunr> that's the user interface part
            <braunr> i'm talking about the implementation
            <desrt> ya -- but it's the interface that makes it unscalable
            <braunr> i know
            <braunr> what i mean is
            <braunr> since the implementation already works like a more modern
              poll
            <braunr> we could in theory add such an interface
            <braunr> but epoll adds some complicated detail
            <desrt> you'll have to forgive me a bit -- i wasn't around from a
              time that i could imagine what a non-modern poll would look like
              inside of a kernel :)
            <braunr> what i mean with a modern poll is a scalable poll-like
              interface
            <braunr> epoll being the reference
            * desrt is not super-crazy about the epoll interface....
            <braunr> me neither
            <desrt> kevent() is amazing -- one syscall for everything you need
            <braunr> i don't know kqueue enough to talk about it
            <desrt> no need to do 100 epollctls when you have a whole batch of
              updates to do
            <desrt> there's two main differences
            <desrt> first is that instead of having a bunch of separate fds for
              things like inotify, timerfd, eventfd, signalfd, etc -- they're
              all built in as different 'filter' types
            <desrt> second is that instead of a separate epoll_ctl() call to
              update the list of monitored things, the kevent() call
              (epoll_wait() equivalent) takes two lists: one is the list of
              updates to make and the other is the list of events to
              return.... so you only do one syscall
            <braunr> well, again, that's the interface
            <braunr> internally, there still are updates and waits
            <braunr> and on a multiserver system like the hurd, this would mean
              one system call per update per fd
            <braunr> and then one per wait
            <desrt> on the implementation side, i think kqueue also has a nice
              feature: the kernel somehow has some magic that lets it post
              events to a userspace queue.... so if you're not making updates
              and you do a kevent() that would not block, you don't even enter
              the kernel
            <braunr> ok
            <desrt> hm.  that's an interesting point
            <desrt> "unix" as such is just another server for you guys, right?
            <braunr> no
            <braunr> that's a major difference between the hurd and other
              microkernel based systems
            <braunr> even multiserver ones like minix
            <braunr> we don't have a unix server
            <braunr> we don't have a vfs server or even an "fd server"
            <desrt> so mach knows about things like fds?
            <braunr> no
            <braunr> only glibc
            <desrt> oh.  weird!
            <braunr> yes
            <braunr> that's the hurd's magic :)
            <braunr> being so posix compliant despite how exotic it is
            <desrt> this starts to feel like msvcrt :p
            <braunr> maybe, i wouldn't know
            <braunr> windows is a hybrid after all
            <braunr> with multiple servers for its file system
            <braunr> so why not
            <braunr> anyway
            <desrt> so windows doesn't have fds in the kernel either... the C
              library runtime emulates them
            <braunr> mach has something close to file descriptors
            <desrt> which is fun when you get into dll hell -- sometimes you
              have multiple copies of the C library runtime in the same program
              -- and you have to take care not to use fds from one of them with
              th o ther one
            <braunr> yes ..
            <braunr> that, i knew :)
            <braunr> but back to the hurd
            <braunr> since fds are a glibc thing here, and because "files" can
              be implemented by multiple servers
            <braunr> (sockets actually most of the time with select/poll)
            <braunr> we have to make per fd requests
            <braunr> the implementation uses the "port set" kernel abstraction
            <desrt> right -- we could have different "fd" coming from different
              places
            <braunr> do you know what a mach port is ?
            <desrt> not even a little bit
            <braunr> hm
            <desrt> i think it's what a plane does when it goes really fast,
              right?
            <braunr> let's say it's a kernel message queue
            <braunr> no it's not a sonic boom
            <desrt> :)
            <braunr> ;p
            <braunr> so
            <braunr> ports are queues
            <desrt> (aside: i did briefly run into mach ports recently on macos
              where they modified their kqueue to support them...)
            <braunr> queues of RPC requests usually
            <desrt> (but i didn't use them or look into them at all)
            <braunr> they can be referenced through mach port names, which are
              integers much like file descriptors
            <braunr> they're also used for replies but, except for weird calls
              like select/poll, you don't need to know that :)
            <braunr> a port set is one object containing multiple ports
            <desrt> sounds like dbus :)
            <braunr> the point of a port set is to provide the ability to
              perform a single operation (wait for a message) on multiple ports
            <desrt> sounds like an epoll fd....
            <desrt> is the port set itself a port?
            <braunr> so, when a client calls select, it translates the list of
              fds into port names, creates reply ports for each of them, puts
              them into a port set, send one select request for each, and does
              one blocking wait on the port set
            <braunr> no, but you can wait for a message on a port set the same
              way you do on a port
            <braunr> and that's all it does
            <desrt> does that mean that you can you put a port set inside of
              another port set?
            <braunr> hm maybe
            <desrt> i guess in some way that doesn't actually make sense
            <braunr> i guess
            <desrt> because i assume that the message you sent to each port in
              your example is "tell me when you have some stuff"
            <braunr> yes
            <desrt> and you'd have to send an equivalent message to the port
              set.... and that just doesn't make sense
            <desrt> since it's not really a thing, per se
            <braunr> it would
            <braunr> insteaf of port -> port set, it would just be port -> port
              set -> port set
            <braunr> but we don't have any interface where an fd stands for a
              port set
            <braunr> what i'm trying to tell here is that
            <braunr> considering how it's done, you can easily see that there
              has to be non trivial communication
            <braunr> each with the cost of a system call
            <braunr> and not just any system call, a messaging one
            <braunr> mach is clearly not as good as l4 when it comes to that
            <desrt> hrmph
            <braunr> and the fact that most pollable fds are either unix or
              inet/inet6 sockets mean that there will be contention in the
              socket servers anyway
            <desrt> i've seen some of the crazy things you guys can do as a
              result of the way mach works and way that hurd uses it, in
              particular
            <desrt> normal users setting up little tcp/ip universes for
              themselves, and so on
            <braunr> yes :)
            <desrt> but i guess this all has a cost
            <braunr> the cost here comes more from the implementation than the
              added abstractions
            <braunr> mach provides async ipc, which can partially succeed
            <desrt> if i spin up a subhurd, it's using the same mach, right?
            <braunr> yes
            <desrt> that's neat
            <braunr> we tend to call them neighbour hurds because of that
            <braunr> i'm not sure it is
            <desrt> it puts it half way between linux containers and outright
              VMs
            <desrt> because you have a new kernel.... ish...
            <braunr> well, it is for the same reasons hypervisors are neat
            <desrt> but the kernel exists within this construct....
            <braunr> a new kernel ?
            <desrt> a new hurd
            <braunr> yes
            <desrt> but not a new mach
            <braunr> exactly
            <desrt> ya -- that's very cool
            <braunr> it's halfway between hypervisors and containers/jails
            <braunr> what matters is that we didn't need to write much code to
              make it work
            <braunr> and that the design naturally guarantees strong isolation
            <desrt> right.  that's what i'm getting at
            <braunr> unlike containers
            <desrt> it shows that the interaction between mach and these set of
              crazy things collectively referred to as the hurd is really
              proper
            <braunr> usually
            <braunr> sometimes i think it's not
            <braunr> but that's another story :)
            <desrt> don't worry -- you can fix it when you port to L4 ;)
            <braunr> eh, no :)
            <desrt> btw: is this fundamentally the same mach as darwin?
            <braunr> yes
            <desrt> so i guess there are multiple separate implementations of a
              standard set of interfaces?
            <braunr> ?
            * desrt has to assume that apple wouldn't be using GNU mach, for
                example...
            <braunr> no it's the same code base
            <braunr> they couldn't
            <braunr> but only because the forks have diverged a bit
            <desrt> ah
            <braunr> and they probably changed a lot of things in their virtual
              memory implementation
            <desrt> so i guess original mach was under some BSDish type thing
              and GNU mach forked from that and started adding GPL code?
            <braunr> something like that
            <desrt> makes sense
            <braunr> we have very few "non-standard" mach interfaces
            <braunr> but we now rely on them so we couldn't use another mach
              either
            <braunr> back to the select/poll stuff
            * desrt gets a lesson tonight :)
            <braunr> it costs, it's not scalable
            <braunr> but
            <braunr> we have scalability problems in our servers
            <braunr> they're old code, they use global locks
            <desrt> right.  this is the story i heard last time.
            <braunr> probably from me
            <braunr> poll works good enough for us right now
            <braunr> we're more interested in bug fixes than scalability
              currently
            <desrt> the reason this negative impacts me is because now i need
              to write a bunch more code ;p
            <braunr> i hope this changes but we still get weird errors that
              many applications don't expect and they react badly to those
            <braunr> well, poll really is the posix fallback
            <desrt> every other OS that we want to support has some sort of new
              scalable epoll-type interface or is Windows (which needs separate
              code anyway)
            <desrt> a very large number of them have kqueue... linux has
              epoll... solaris/illumos is the odd one out with this weird thing
              that's sort of like epoll
            <braunr> i would think you want a posix fallback for such a
              commonly used interface
            <braunr> hm
            <desrt> braunr: hurd is pretty much the only one that doesn't
              already have something better....
            <braunr> linux can be built without epoll
            <desrt> and the nice thing about all of these things is that every
              single one of them gives me an fd that can be polled when any
              event is ready
            <braunr> i don't see why anyone would do that, but it's a compile
              time option ;p
            <braunr> yes ...
            <braunr> we don't have xxxfd() :)
            <desrt> and we want to expose that fd on our API... so people can
              chain gmaincontext into other mainloops
            <braunr> that's expected
            <desrt> so for hurd this means that i will need to spin up a
              separate thread doing poll() and communicating back to the main
              thread when anything becomes ready
            <desrt> i was looking forward to not having to do that :)
            <braunr> it matches the unix "everything is a file" idea, and
              windows concept of "events"
            <braunr> i understand but again, it's a posix fallback
            <braunr> you probably want it anyway
            <desrt> probably
            <braunr> it could help new systems trying to be posix like
            <desrt> i honestly thought i'd get away with it, though
            <desrt> this is true...
            <desrt> CLOCK_MONOTONIC is an easy enough requirement to implement
              or fake.... "modern event polling framework" is another story...

        [[service_solahart_jakarta_selatan__082122541663/clock_gettime]].

            <braunr> yes, but again, we do have the underlying machinery to add
              it
            <desrt> i appreciate if your priorities are elsewhere ;)
            <braunr> it's just not worth the effort right now
            <braunr> although we do have performance and latency improvements
              in our patch queues currently
            <braunr> if our network stack gets replaced, it would become
              interesting
            <braunr> we need to improve posix compliance first
            <braunr> make more applications not choke on unecpected errors
            <braunr> and then we can think of improving scalability
            <desrt> +1 vote from me for implementing monotonic time :)
            <desrt> (and also pthread_condattr_setclock())
            <braunr> and we probably won't implement the epoll interface ;p
            <braunr> yes
            <desrt> it's worth noting that there is also a semi-widely
              available non-standard extension called
              pthread_cond_timedwait_relative_np that you could implement
              instead
            <desrt> it takes a (relative) timeout instead of an absolute one --
              we can use that if it's available
            <braunr> desrt: why would you want relative timeouts ?
            <desrt> braunr: if you're willing to take the calculations into
              your own hands and you don't have another way to base it on
              monotonic time it starts to look like a good alternative
            <desrt> and indeed, this is the case on android and macos at least
            <braunr> hm
            <desrt> not great as a user-facing API of course.... due to the
              spurious wakeup possibility and need to retry
            <braunr> so it's non standard alternative to a monotonic clock ?
            <desrt> no -- these systems have monotonic clocks
            <desrt> what they lack is pthread_condattr_setclock()
            <braunr> oh right
            <desrt> which is documented in POSIX but labelled as 'optional'
            <braunr> so relative is implicitely monotonic
            <desrt> yes
            <desrt> i imagine it would be the same 'relative' you get as the
              timeout you pass to poll()
            <desrt> since basing anything like this on wallclock time is
              absolutely insane
            <desrt> (which is exactly why we refuse to use wallclock time on
              our timed waits)
            <braunr> sure
            <braunr> i'm surprised clock_monotonic is even optional in posix
              2008
            <braunr> but i guess that's to give some transition margin for
              small embedded systems
            <desrt> when you think about it, CLOCK_REALTIME really ought to
              have been the optional feature
            <desrt> monotonic time is so utterly basic
            <braunr> yes
            <braunr> and that's how it's normally implemented
            <braunr> kernels provide a monotonic clock, and realtime is merely
              shifted from it

      * <a id=sys_eventfd.h>`sys/eventfd.h`</a>

      * <a id=sys_inotify.h>`sys/inotify.h`</a>

      * <a id=sys_signalfd.h>`sys/signalfd.h`</a>

      * <a id=sys_timerfd.h>`sys/timerfd.h`</a>

      * <a id=timespec_get>`timespec_get` (74033a2507841cf077e31221de2481ff30b43d51,
        87f51853ce3671f4ba9a9953de1fff952c5f7e52)</a>

      * <a id=waitflags.h>`waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`)</a>

        IRC, freenode, #hurd, 2012-04-20:

            <pinotree> in glibc, we use the generic waitflags.h which, unlike
              linux's version, does not define WEXITED, WNOWAIT, WSTOPPED,
              WCONTINUED
            <pinotree> should the generic bits/waitflags.h define them anyway,
              since they are posix?
            <youpi> well, we'd have to implement them anyway
            <youpi> but otherwise, I'd say yes
            <pinotree> sure, but since glibc headers should expose at least
              everything declared by posix, i thought they should be defined
              anyway
            <youpi> that might bring bugs
            <youpi> some applications might be #ifdefing them
            <youpi> and break when they are defined but not working
            <pinotree> i guess they would define them to 0, andd having them to
              non-zero values shouldn't break them (since those values don't do
              anything, so they would act as if they were 0.. or not?)
            <youpi> no, I mean they would do something else, not define them to
              0
            <pinotree> like posix/tst-waitid.c, you mean?
            <youpi> yes

        See `posix/tst-waitid.out` failure below.

      * <a id=getconf>`getconf` things (see below the results of `tst-getconf.out`)</a>

      * <a id=getsockopt>`getsockopt`, `setsockopt`</a>

        IRC, freenode, #hurd, 2013-02-14

            <gnu_srs> Hi, {get,set}sockopt is not supported on Hurd. This shows
              e.g. in the gnulib's test-{poll,select} code.
            <gnu_srs> Reading
              http://hea-www.harvard.edu/~fine/Tech/addrinuse.html there might
              be reasons _not_ to implement them, comments?
            <pinotree> uh? they are supported on hurd
            <gnu_srs> not  SO_REUSEPORT for setsockopt()
            <pinotree> that isn't the same as claiming "get/setsockopt is not
              supported on hurd"
            <pinotree> most probably that option is not implemented by the
              socket family you are using
            <gnu_srs> OK, some options like  SO_REUSEPORT then, more info in
              the link.
            <pinotree> note also SO_REUSEPORT is not posix
            <pinotree> and i don't see SO_REUSEPORT mentioned in the page you
              linked
            <gnu_srs> No, but SO_REUSEADDR

        IRC, freenode, #hurd, 2013-02-23

            <gnu_srs> as an example, the poll test code from gnulib fails due
              to that problem (and I've told you before)
            <pinotree> gnu_srs: what's the actual failure?
            <pinotree> can you provide a minimal test case showing the issue?
            <gnu_srs> pinotree: A smaller test program:
              http://paste.debian.net/237495/
            <pinotree> gnu_srs: setting SO_REUSEADDR before binding the socket
              works...
            <pinotree> and it seems it was a bug in the gnulib tests, see
              http://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=6ed6dffbe79bcf95e2ed5593eee94ab32fcde3f4
            <gnu_srs> pinotree: You are right, still the code I pasted pass on
              Linux, not on Hurd.
            <pinotree> so?
            <pinotree> the code is wrong
            <pinotree> you cannot change what bind does after you have called
              it
            * pinotree → out
            <gnu_srs> so linux is buggy?
            <braunr> no, linux is more permissive
            <braunr> (at least, on this matter)

      * <a id=getcontext>`getcontext`/`makecontext`/`setcontext`/`swapcontext`</a>

        Support for these functions within the Hurd threadvar environment has
        been added, but for multi-threaded applications ([[service_solahart_jakarta_selatan__082122541663/libpthread]]), it is
        a bit clunky: as a practical requirement, a thread's stack size always
        has to be equal to `PTHREAD_STACK_DEFAULT`, 2 MiB, and also has to be
        naturally aligned.  The idea is still to [[get rid of Hurd threadvars
        and replace them with TLS|service_solahart_jakarta_selatan__082122541663/glibc/t/tls-threadvar]].

        Aside from [[gccgo]], the following packages might make use of these
        functions, searching on <http://codesearch.debian.net/> for
        `\b(get|set|make|swap)context\s*\(` on 2013-05-18: boost1.49,
        chromium-browser, gtk-vnc, guile-1.8, iceape, icedove, iceweasel,
        libgc, libsigsegv, luatex, mono, nspr, pth, ruby1.8, texlive-bin, uim,
        and more.

        IRC, OFTC, #debian-hurd, 2013-09-08:

            <pinotree> oh, and even ruby2.0 suffers because of fixed-stack
              threads
            <youpi> yes, we definitely need to finish fixing it
            <youpi> my current work is in our glibc repo, youpi/tls-threadvar
            <pinotree> | *** makecontext: a stack at 0xbc000 with size 0x40000
              is not usable with threadvars
            <pinotree> all 8 failing tests with that
            <youpi> maybe we can hand-disable the use of contexts in ruby for
              now?
            <pinotree> gg0: ↑ :)
            <gg0> after the pseudo-patch i RFCed, i don't deserve to say
              anything else about that :)
            <pinotree> i mean, feel free to investigate and "fix" ruby2.0 as
              above :)
            <gg0> eh maybe i'd just be able to hand-disable failing
              thread-related _tests_ :)
            <gg0> i'm still hoping some real developer picks and actually fixes
              it, seems it's not enough interesting though
            <azeem> 21:37 < youpi> yes, we definitely need to finish fixing it
            <gg0> afaiu youpi is working on threadvars-tls migration, which
              would mean fixing them all. i just meant fixing ruby, which would
              mean having puppet btw
            <youpi> gg0: "actually fixing" means fixing threadvars-tls
              migration
            <youpi> "just fixing" ruby can be done by simply disabling context
              use in ruby

        IRC, OFTC, #debian-hurd, 2013-09-10:

            <gg0> this one fixes make test by disabling context and giving more
              time to timing related tests http://paste.debian.net/plain/37977/
            <gg0> make test-all is another story
            <youpi> gg0: AIUI, the sleep part should get fixed by the next
              glibc upload, which will include the getclk patch
            <youpi> but the disabling context part could be good to submit to
              the debian ruby package, mentioning that this is a workaround for
              now
            <gg0> unfortunately still not enough, test-all still fails
            <youpi> does it make the package not build?
            <gg0> test-all is the second part of what we call tests
            <gg0> they build and package (they produce all ruby packages),
              after that they run debian/run-test-suites.bash which is make
              test + make test-all
            <gg0> well after or during the build doesn't matter, it's their
              testsuite
            <gg0> ok just failed:
            <gg0> TestBug4409#test_bug4409 = Illegal instruction
            <gg0> make: *** [yes-test-all] Error 132
            <gg0> what to do with Illegal instruction?
            <gg0> just found 2 words that make everybody shut up :p
            <pinotree> same as above: debug it
            <teythoon> gg0: have you confirmed that this is reproducible? I've
              once had a process die with SIGILL and it was not and I figured
              it might have been a (qemu?) glitch
            <gg0> seems i'm running tests which are disabled on _all_ archs,
              better so
            <gg0> well, this should be reproducible. i just got it on a qemu, i
              could try to reproduce it on real hardware but as just said, i
              was testing tests disabled by maintainer so completely useless
            <teythoon> gg0: yeah, I'm running all my hurd instances on qemu/kvm
              as well, I meant did you get this twice in a row?
            <gg0> to be honest i got another illegal instruction months ago but
              don't recall doing what
            <gg0> nope not twice, i've commented it out. then run the remaining
              and then found out i should not have done what i was doing
            <gg0> but i could try to reproduce it
            <gg0> ok now i recall i got it another one few hours ago on real
              hardware, from logs:
            <gg0> TestIO#test_copy_stream_socket = Illegal instruction
            <gg0> teythoon: on real hardware though
            <gg0> and this is the one i should debug once it finishes, still
              running

        IRC, freenode, #hurd, 2013-09-11:

            <gg0_> ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind:
              Assertion `! __spin_lock_locked (&ss->critical_section_lock)'
              failed.
            <gg0_> and
            <gg0_> ../libpthread/sysdeps/mach/pt-thread-halt.c:51:
              __pthread_thread_halt: Unexpected error: (ipc/send) invalid
              destination port.
            <tschwinge> gg0_: Which libpthread source are these?  Stock Debian
              package?
            <gg0_> tschwinge: everything debian, ruby rebuilt with
              http://paste.debian.net/plain/38519/ which should disable
              *context

        IRC, OFTC, #debian-hurd, 2013-09-11:

            <gg0_> wrt ruby, i'd propose a patch that disables *context and
              comments out failed tests (a dozen). most of them are timing
              related, don't always fail
            <gg0_> if they failed gracefully, we could leave them enabled and
              just ignoring testsuite result, but most of them block testsuite
              run when fail
            <gg0_> anyone against? any better idea (and intention to implement
              it? :p)?
            <gg0_> youpi: is disabling some tests acceptable? ^
            <youpi> it'd be good to at least know what is failing
            <youpi> so as to know what impact hiding these failures will have
            <youpi> remember that hiding bugs usually means getting bitten by
              them even harder later :)
            <gg0_> many of them use pipes
            <gg0_> here the final list, see commented out ones
              http://paste.debian.net/plain/38426
            <gg0_> and as said some don't always fails
            <gg0_> test_copy_stream_socket uses a socket
            <youpi> note that we can still at least build packages with notest
            <youpi> at least to get the binaries uploaded
            <youpi> disabling *context should however really be done
            <youpi> and the pipe issues are concerning
            <youpi> I don't remember other pipe issues
            <youpi> so maybe it's a but in the ruby bindings
            <gg0_> i just remember they didn't die, then something unknown
              fixed it
            <youpi> I see something frightening in io.c
            <youpi> #if BSD_STDIO
            <youpi>          preserving_errno(fseeko(f, lseek(fileno(f),
              (off_t)0, SEEK_CUR), SEEK_SET));
            <youpi> #endif
            <youpi> this looks very much like a workaround for an odd thing in
              BSD
            <youpi> it happens that that gets enabled on hurd too, since
              __MACH__ is defined
            <youpi> you could try to drop these three lines, just to see
            <youpi> this is very probably very worth investigating, at any rate
            <youpi> even just test_gets_limit_extra_arg is a very simple test,
              that I fail to see why it should ever fail on hurd-i386
            <youpi> starting debugging it would be a matter of putting printfs
              in io.c, to check what gets called, with what parameters, etc.
            <youpi> just a matter of taking the time to do it, it's not very
              complex
            <gg0_> youpi: are you looking at 1.8? no BSD_STDIO here
            <youpi> yes, 1.8
            <gg0_> 1.9.3.448
            <gg0_> landed to sid few days ago
            <youpi> ah, I have 1.87
            <youpi> +.
            <gg0_> my favourites are TestIO#test_copy_stream_socket and
              TestIO#test_cross_thread_close_fd -> Illegal instruction
            <gg0_> TestIO#test_io_select_with_many_files sometimes Illegal
              instruction, sometimes ruby1.9.1:
              ../sysdeps/mach/hurd/jmp-unwind.c:53: _longjmp_unwind: Assertion
              `! __spin_lock_locked (&ss->critical_section_lock)' failed.

        [[thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock]]?

            <gg0_> trying to debug illegal instruction
              http://paste.debian.net/plain/38585/
            <gg0_> (yes, i'm not even good at gdbing)
            <gg0_> any hint?
            <gg0_> oh found out there's an intree .gdbinit, that might
              complicate things

        IRC, OFTC, #debian-hurd, 2013-09-13:

            <gg0_> where should it be implemented MAP_STACK? plus, is it worth
              doing it considering migration to tls, wouldn't it be useless?
            <gg0_> sysdeps/mach/hurd/mmap.c i should reduce stupid questions
              frequency from daily to weekly basis

        IRC, OFTC, #debian-hurd, 2013-09-14:

            <gg0_> say i managed to mmap 0x200000-aligned memory
            <gg0_> now i get almost the same failed tests i get disabling
              *context
            <gg0_> that would mean they don't depend on threading

        IRC, freenode, #hurd, 2013-09-16:

            <gg0> i get many ../sysdeps/mach/hurd/jmp-unwind.c:53:
              _longjmp_unwind: Assertion `! __spin_lock_locked
              (&ss->critical_section_lock)' failed.
            <gg0> by running ruby testsuite, especially during test_read* tests
              http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L972
            <gg0> read/write operations with pipes
            <braunr> gg0: that's weird
            <braunr> gg0: debian glibc ?
            <gg0> braunr: yep, debian 2.17-92
            <gg0> sometimes assertion above, sometimes tests in question get
              stuck reading
            <gg0> it would be nice reproducing it w/o ruby
            <gg0> probably massive io on pipes could do the job
            <gg0> also more nice finding someone who finds it interesting to
              fix :p
            <gg0> ruby is rebuilt with http://paste.debian.net/plain/40755/, no
              *context
            <gg0> pipe function in tests above creates one thread for write,
              one for read
              http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L26
            <tschwinge> gg0: About the jmp-unwind assertion failure: is it be
              chance this issue:
              <http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html>?
              I didn't look in detail.
            <braunr> tschwinge: that's what i thought too about the assertion,
              which is why i find it strange
            <gg0> asserting it's not locked then locking it doesn't exclude
              race conditions

        IRC, OFTC, #debian-hurd, 2013-09-17:

            <gg0> youpi: i guess no one saw it anymore since
              tg-thread-cancel.diff patch
            <gg0> it =
              http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html
            <gg0> this one comes from sysdeps/mach/hurd/jmp-unwind.c:53 though
            <gg0> another assertion to remove?
            <youpi> gg0: it's not exactly the same: in hurd_thread_cancel we
              hold no lock at all at the assertion point
            <youpi> in jmp-unwind.c, we do hold a lock
            <youpi> and the assertion might be actually true because all other
              threads are supposed to hold the first lock before taking the
              other one
            <youpi> you could check for that in other places
            <youpi> and maybe it's the other place which wouldhave to be fixed
            <youpi> also look for documentation which would say that

        IRC, freenode, #hurd, 2013-09-17:

            <braunr_> gg0: is that what we do ??
            <gg0> braunr: well, i was looking at
              http://sources.debian.net/src/eglibc/2.17-92/debian/patches/hurd-i386/tg-thread-cancel.diff
            <gg0> which afaics fixes
              http://www.gnu.org/software/hurd/open_issues/thread-cancel_c_55_hurd_thread_cancel_assertion___spin_lock_locked_ss_critical_section_lock.html
            <gg0> the one i get now is
              http://sources.debian.net/src/eglibc/2.17-92/sysdeps/mach/hurd/jmp-unwind.c#L53
            <gg0> 09:12 < youpi> gg0: it's not exactly the same: in
              hurd_thread_cancel we hold no lock at all at the assertion point
            <gg0> 09:13 < youpi> in jmp-unwind.c, we do hold a lock
            <gg0> 09:13 < youpi> and the assertion might be actually true
              because all other threads are supposed to hold the first lock
              before taking the other one
            <braunr> gg0: that assertion is normal
            <braunr> it says there is a deadlock
            <braunr> ss->critical_section_lock must be taken before ss->lock
            <gg0> you mean ss->lock before ss->critical_section_lock
            <braunr> no
            <gg0> ah ok got it
            <braunr> that's a bug
            <braunr> longjmp
            <braunr> ugh
            <braunr> you could make a pass through the various uses of those
              locks and check what the intended locking protocol should be
            <braunr> i inferred ss->critical_section_lock before ss->lock from
              hurd_thread_cancel
            <braunr> this might be wrong too but considering this function is
              used a lot, i doubt it
            <gg0> (no, i hadn't got it, i was looking at jmp-unwind.c where
              lock is before critical_section_lock)
            <gg0> could we get useful info from gdb'ing the assertion?
            <tschwinge> gg0: Only if you first get an understanding why it is
              happening, what you expect to happen instead/why it shall not
              happen/etc.  Then you can perhaps use GDB to verify that.
            <gg0> i can offer an irc interface if anyone is interested, it's
              ready, just to attach :)
            <gg0> this is the test
              http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L937
            <gg0> pipe function creates two threads
              http://sources.debian.net/src/ruby1.9.1/1.9.3.448-1/test/ruby/test_io.rb#L26
            <gg0> Attaching to pid 15552
            <gg0> [New Thread 15552.1]
            <gg0> [New Thread 15552.2]
            <gg0> (gdb) 

        IRC, freenode, #hurd, 2013-09-21:

            <youpi> gg0: it seems the assert (! __spin_lock_locked
              (&ss->critical_section_lock)); is bogus
            <youpi> but it'd be good to catch a call trace
            <youpi> well, it may not be bogus, in case that lock is only ever
              taken by the thread itself
            <youpi> in that case, inside longjmp_unwind we're not supposed to
              have it already
            <youpi> ok, that's what we had tried to discuss with Roland
            <youpi> it can happen when playing with thread cancelation
            <braunr> youpi: the assertion isn't exactly bogus
            <braunr> the lock ordering is
            <youpi> braunr: which one are you talking about?
            <youpi> the one in hurd_thread_cancel looks really wrong
            <youpi> and some parts of the code keep the critical section lock
              without ss->lock held, so I don't see how lock ordering can help

        IRC, OFTC, #debian-hurd, 2013-09-22:

            <gg0> how much does this patch suck on a scale from 1 to 10?
              http://paste.debian.net/plain/44810/
            <youpi> well, the stack allocation issue will go away once I get
              the threadvars away
            <youpi> I'm working on it right now
            <youpi> about the lib paths, it makes sense to add the gnu case,
              but i386-gnu shouldn't be put in the path
            <gg0> that's great
            <gg0> so seems the wrong moment for what i've already done
              ie. asking terceiro what he thinks about patch above :/
            <gg0> any distro-independent way to get libc.so and libm.so path?
            <gg0> ruby as last resource takes them from "ldd ruby"
            <pinotree> gg0: should work fine then
            <gg0> well it does. but gnu doesn't have a case so it hits default
              which is broken
              http://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/40235/entry/test/dl/test_base.rb
            <gg0> btw even linux and kfreebsd with debian multipath have broken
              cases but they don't hit default and get fixed by ldd later
            <pinotree> why it is broken? are arguments passed to that script?
            <gg0> i'm not sure about what propose. a broken case so it doesn't
              hit default like linux and kfbsd
            <gg0> yes they are :/
            <pinotree> and which ones are? who executes that script and which
              arguments does it pass to it?
            <gg0> other ruby scripts which have nothing to do with libc/libm
            <pinotree> well, if they pass arguments which should be the paths
              to libc and libm, they must be getting such paths, aren't they?
            <gg0> they don't. arguments are other ruby scripts, don't know why,
              maybe something else broken before
            <gg0> but that would mean that before there's a smarter path
              detection way, i doubt
            <pinotree> then add the case for hurd, but setting both libc and
              libm as nil
            <pinotree> so they will be fetched again
            <gg0> yep and would really ugly
            <gg0> +be
            <gg0> "please commit this one which wrongly sets paths."
            <gg0> an alternative would be removing default case
            <gg0> or pointing it out by proposing ldd in hurd case might make
              them review the whole detection
            <gg0> by setting correct paths like in patch above it wouldn't
              break a possible hurd-amd64, it would work due to ldd
            <youpi> gg0: that's why I said the patch is fine, but without the
              i386-gnu part of the path
            <youpi> just like it happens to be on linux & kfreebsd
            <gg0> i might take ldconfig -p output
            <gg0> to make it uselessly correct from start
            <gg0> http://bugs.ruby-lang.org/issues/8937
            <pinotree> note thar ruby 1.8 is EOL
            <pinotree> *that
            <gg0> -- If you're reporting a bug in both Ruby 1.9/2.0 and Ruby
              1.8: ruby-trunk, and write like "this bug can be reproduced in
              Ruby 1.8 as well." --
            <gg0> i suspect this one won't be the only one i'll file. unless
              upcoming youpi's tls and braunr's thread destruction patches fix
              all ruby tests
            <pinotree> did you check ruby2.0 too, btw?
            <gg0> switched to ruby2 few hours ago. i pointed out 2nd part of
              testsuite is not enabled, probably terceiro will enable it soon
            <gg0> by applying my patch above we'd completely fix current
              ruby2.0 build (yes because tests are not completely enabled)
            <pinotree> what you run those extra tests?
            <gg0>
              http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/run-test-suites.bash
            <gg0> make test + make test-all
            <gg0> (test-all is 2nd part)
            <gg0> many are problematic. i didn't finish yet to suppress them
              one-by-one. one i suppress, another one pops up
            <gg0> either get stuck or well known assertion
            <pinotree> check those that get stuck :)
            <gg0> which kind of check?
            <pinotree> "check" as in "debug"
            <gg0> btw i tested puppet few days ago (with ruby1.8), it seems to
              be working, at least at trasferring files from master
            <gg0> don't know about any advanced usage
            <pinotree> ruby 1.8 is going to die soon, so testing things against
              it is not totally useful
            <gg0> so you assume 1.8 is less broken than 1.9/2.0, right?
            <pinotree> no
            <gg0> i just can see it's been built without tests itself too
            <pinotree> erm no
            <gg0> well ok, if i can be wrong, i'll be wrong
            <gg0> i say that after a quick check time ago, might be wrong
            <pinotree> `getbuildlogs ruby1.8 last hurd-i386`, see the last
              build log
            <gg0> ah from pkg-kde-tools
            <gg0> i hate kde :)
            <pinotree> no?
            <gg0> no what?
            <pinotree> devscripts: /usr/bin/getbuildlog
            <gg0> pkg-kde-tools: /usr/bin/pkgkde-getbuildlogs
            <pinotree> which is not what i said
            <gg0> wait that's what apt-file found
            <gg0> maybe i should update it
            <gg0> is it so recent?
            <pinotree> no
            <pinotree> i just added an 's' more at the end of the command, but
              typing getbu<tab> could have been helpful anyway...
            <gg0> yeah just got it
            <gg0> my fault not to have tried to run it before looking for it
            <pinotree> and btw, i don't see what hating kde has to do with
              tools developed by qt/kde debian packagers
            <gg0> j/k i simply don't use kde, never used and apt-file search
              told me it was from pkg-kde-tools
            <gg0> btw build log says "make test" fails, doesn't even start. and
              its failure doesn't block the build
            <pinotree> exactly
            <gg0> s/make test/make test-all/
            <gg0> "make test" (aka "1st part" above) doesn't run. i guess it's
              missing in packaging

        IRC, freenode, #hurd, 2013-09-22:

            <braunr> youpi: i mean the lock order where the assertion occurs is
              reserved compared to the one in hurd_thread_cancel
            <braunr> (and the one in hurd_thread_cancel is the same used in
              hurd condition-related functions)
            <youpi> "reserved" ?
            <braunr> reversed
            <braunr> :)
            <youpi> by "the assertion occurs", you mean gg0's spot?
            <braunr> yes
            <youpi> well , the assertion also happens in hurd_thread_cancel
            <braunr> it does oO
            <braunr> i didn't see that
            <youpi> but otherwise yes, it's completely bogus that we have both
              locking in different orders
            <youpi> could you submit the fix for jmp-unwind.c to upstream?
            <braunr> what fix ?
            <youpi> reversing the lock order
            <braunr> ah, simply that
            <youpi> (well, provided that hurd_thread_cancel is right)
            <braunr> that's what i suggested to gg0
            <braunr> to check where those locks are held and determine the
              right order

        IRC, OFTC, #debian-hurd, 2013-09-28:

            <gg0_> now we'd just need tls
            <gg0_> http://bugs.ruby-lang.org/issues/8937
            <gg0_> well, it would pass makecheck at least. makecheckall would
              keep hanging on threads/pipes tests i guess, unless tls/thread
              destruction patches fix them

        IRC, OFTC, #debian-hurd, 2013-10-05:

            <youpi> so what is missing for ruby2.0, only disabling use of
              context for now, no?
            <pinotree> i'm not tracking it closely, gg0_ is
            <gg0_> maybe terceiro would accept a patch which only disables
              *context, "maybe" because he rightly said changes must go
              upstream
            <gg0_> anyway with or without *context, many many tests in
              makecheckall fail by making it hang, first with and without
              assertion you removed, now they all simply hang
            <gg0_> youpi: what do we want to do? if you're about finishing tls
              migration (as i thought a couple of weeks ago), i won't propose
              anything upstream. otherwise i could but that will have to be
              reverted upstream once you finish
            <gg0_> about tests, current ruby2.0 doesn't run makecheckall, only
              makecheck which succeeds on hurd (w/o context)
            <gg0_> if anyone wants to give it a try:
              http://paste.debian.net/plain/51089
            <gg0_> first hunk makes makecheck (not makecheckall) succeed and
              has been upstreamed, not packaged yet
            <pinotree> what about makecheckall for ruby2.0?
            <gg0_> 16:58 < gg0_> anyway with or without *context, many many
              tests in makecheckall fail by making it hang, first with and
              without assertion you  removed, now they all simply hang
            <pinotree> i for a moment thought it as for 1.9.1, ok
            <pinotree> these hangs should be debugged, yes
            <gg0_> nope, tests behavior doesn't change between 1.9 and 2.0. i
              started suppressing tests onebyone on 2.0 as well and as happened
              on 1.9, i gave up cause there were too many
            <gg0_> yep a smart mind could start debugging them, starting from
              patch above pasted by a lazy one owner
            <gg0_> one problem is that one can't reproduce them by isolate
              them, they don't fail. start makecheckall then wait for one fail
            <gg0_> now after my stupid report, someone like pinotree could take
              it over, play with it for half an hour/an hour (which equals to
              half a gg0's year/a gg0's year
            <gg0_> )
            <gg0_> and fix them all

            <gg0_> 17:05 < gg0_> youpi: what do we want to do? if you're about
              finishing tls migration (as i thought a couple of weeks ago), i
              won't propose  anything upstream. otherwise i could but that will
              have to be reverted upstream once you finish
            <youpi> gg0_: I don't really know what to answer
            <youpi> that's why I didn't answer :)
            <gg0_> youpi: well then we could upstream context disable and keep
              it disabled even if you fix tls. ruby won't be as fast as it
              would be with context but i don't think anyone will complain
              about that. then once packaged, if terceiro doesn't enable
              makecheckall, we will have ruby2.0 in main
            <youpi> that can be a plan yes
            <gg0_> btw reverting it upstream should not be a problem eventually
            <youpi> sure, the thing is remembering to do it
            <gg0_> filed http://bugs.ruby-lang.org/issues/8990
            <gg0_> please don't fix tls too soon :)
            <gg0_> s/makecheck/maketest/g

        IRC, OFTC, #debian-hurd, 2013-10-08:

            <gg0_> ok. *context disabled http://bugs.ruby-lang.org/issues/8990

            <gg0> bt full of an attached stuck ruby test
              http://paste.debian.net/plain/53788/
            <gg0> anything useful?
            <youpi> uh, is that really all?
            <youpi> there's not much interesting unfortunately
            <youpi> did you run thread apply all bt full ?
            <youpi> (not just bt full)
            <gg0> no just bt full
            <gg0> http://paste.debian.net/plain/53790/
            <gg0> wait, there's a child
            <gg0> damn ctrl-c'ing while it was loading symbols made it crash :/
            <gg0> restarted testsuite
            <gg0> isn't it interesting that failed tests fail only if testsuite
              runs from beginning, whereas if run singularly, they succeed?
            <gg0> as it got out of whatever resources
            <gg0> youpi: http://paste.debian.net/plain/53798/
            <youpi> the interesting part is actually right at the top
            <youpi> it's indeed stuck in the critical section spinlock
            <youpi> question being what is keeping it
            <youpi> iirc I had already checked in the whole glibc code that all
              paths which lock  critical_section_lock actually release it in
              all cases, but maybe I have missed some
            <youpi> (I did find some missing paths, which I fixed)
            <gg0> i guess the same check you and braunr talk about in
              discussion just before this anchor
              http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg
            <youpi> yes, but the issue we were discussing there is not what
              happens here
            <youpi> we would see another thread stuck in the other way roudn,
              otherwise
            <gg0> no way to get what is locking?
            <youpi> no, that's not recorded
            <gg0> and what about writing it somewhere right after getting the
              lock?
            <youpi> one will have to do that in all spots taking that lock
            <youpi> but yes, that's the usual approach
            <gg0> i would give it try but eglibc rebuild takes too much time,
              that conflicts with my laziness
            <gg0> i read even making locks timed would help

        IRC, OFTC, #debian-hurd, 2013-10-09:

            <gg0> so correct order would be:
            <gg0> __spin_lock (&ss->lock); // locks sigstate
            <gg0> __spin_lock (&ss->critical_section_lock);
            <gg0> [do critical stuff]
            <gg0> __spin_unlock (&ss->critical_section_lock);
            <gg0> __spin_unlock (&ss->lock);  // unlocks sigstate
            <gg0> ?

            <gg0> 21:44 < gg0> terceiro: backported to 2.0 (backport to 1.9 is
              waiting) https://bugs.ruby-lang.org/issues/9000
            <gg0> 21:46 < gg0> that means that if you take a 2.0 snapshot,
              it'll build fine on hurd (unless you introduce maketestall as in
              1.9, that would make it get stuck like 1.9)
            <gg0> 21:48 < terceiro> gg0: nice
            <gg0> 21:48 < terceiro> I will try to upload a snapshot as soon as
              I can
            <gg0> 21:52 < gg0> no problem. you might break my "conditional
              satisfaction" by adding maketestall. better if you do that on
              next+1 upload so we'll have at least one 2.0 built :)

            <gg0> would it be a problem granting me access to a porter box to
              rebuild eglibc+ruby2.0?
            <gg0> i'm already doing it on another vm but host often loses power
            <pinotree> you cannot install random stuff on a porterbox though
            <gg0> i know i'd just need build-deps of eglibc+ruby2.0 i guess
            <gg0> (already accessed to porter machines in the past, account
              lele, mips iirc)
            <gg0> ldap should remember that
            <gg0> don't want to disturb anyone else work btw. if it's not a
              problem, nice. otherwise no problem
            <pinotree> please send a request to admin@exodar.debian.net so it
              is not forgotten
            <gg0> following this one would be too "official"?
              http://dsa.debian.org/doc/guest-account/
            <pinotree> hurd is not a release architecture, so hurd machines are
              not managed by DSA
            <gg0> ok
            <pinotree> the general procedure outlines is ok though, just need
              to be sent to the address above
            <gg0> sent
            <gg0> (1st signed mail with mutt, in the worst case i've attached
              passphrase :))
            <youpi> gg0: could you send me an ssh key?
            <pinotree> no alioth account?
            <youpi> yes, but EPERM
            <gg0> youpi: sent to youpi@
            <youpi> youpi@ ?
            <gg0> (... which doesn't exist :/)
            <gg0> sthibault@
            <youpi> please test gg0-guest@exodar.debian.net ?
            <youpi> (I'd rather not adduser the ldap name, who knows what might
              happen when you get your DD account)
            <gg0> i'm in. thanks
            <youpi> you're welcome
            <gg0> ldap users need to be adduser'ed?
            <youpi> I'm not getting your ldap user account from ud-replicate,
              at least
            <gg0> (btw i never planned to apply nm, i'd be honoured but i
              simply think not to deserve it)
            <youpi> never say never ;)
            <gg0> bah i like failing. that would be a success. i can't :)
            <gg0> gg0-guest@exodar:~$ dchroot   
            <gg0> E: Access not authorised
            <gg0> I: You do not have permission to access the schroot service.
            <gg0> I: This failure will be reported.
            <youpi> ah, right, iirc I need to add you somewhere
            <youpi> gg0: please retry?
            <gg0> works
            <youpi> good
            <gg0> are there already eglibc+ruby2.0 build-deps?
            <youpi> yes
            <gg0> oh that means i should do something myself now :)
            <youpi> yep, that had to happen at some point :)
            <gg0> my laziness thanks: "at some point" is better than "now" :)

        IRC, freenode, #hurd, 2013-10-10:

            <gg0> ok just reproduced the
              former. ../sysdeps/mach/hurd/jmp-unwind.c:53 waits
            <braunr> 20:37 < braunr> gg0: does ruby create and destroy threads
              ?
            <gg0> no idea
            <gg0> braunr: days ago you and youpi talked about locking order
              (just before this anchor
              http://darnassus.sceen.net/~hurd-web/open_issues/glibc/#recvmmsg)
            <braunr> oh right
            <gg0> <youpi> could you submit the fix for jmp-unwind.c to
              upstream?
            <braunr> it didn't made it in the todo list
            <gg0> so correct order is in hurd_thread_cancel, right?
            <braunr> sorry about that
            <braunr> we need to make a pass to make sure it is
            <gg0> that means locking first ss->critical_section_lock _then_
              ss->lock
            <gg0> correct?
            <braunr> but considering how critical hurd_thread_cancel is, i
              expect so

            <gg0> i get the same deadlock by swapping locks
            <gg0> braunr: youpi: fyi ^
            <gg0> 20:51 < braunr> 20:37 < braunr> gg0: does ruby create and
              destroy threads ?
            <gg0> how could i check it?
            <braunr> gg0: ps -eflw
            <youpi> gg0: that's not surprising, since in the b acktrace you
              posted there isn't another thread locked in the other order
            <youpi> so it's really that somehow the thread is already in
              critical sesction
            <braunr> youpi: you mean there is ?
            <braunr> ah, it's not the same bug
            <youpi> no, in what he posted, no other thread is stuck 
            <youpi> so it's not a locking order
            <youpi> just that the critical section is actually busy
            <gg0> youpi: ack
            <gg0> braunr: what's the other bug? ext2fs one?
            <braunr> gg0: idk
            <gg0> braunr: thanks. doesn't show threads (found -T for that) but
              at least doesn't limit columns number if piped (thanks to -w)
            <braunr> it does
            <braunr> there is a TH column
            <gg0> ok thread count. -T gives more info

        IRC, freenode, #hurd, 2013-10-24:

            <youpi> ruby2.0 builds fine with the to-be-uploaded libc btw
            <gg0> youpi: without d-ports patches? surprise me :)
            <youpi> gg0: plain main archive source
            <gg0> you did it. surprised
            <gg0> ah ok you just pushed your tls. great!
            <braunr> tls will fix a lot of things

        IRC, OFTC, #debian-hurd, 2013-11-03:

            <youpi> gg0: 
            <youpi> #252 test_fork.rb:30:in `<top (required)>': core dumped
              [ruby-core:28924]
            <youpi> FAIL 1/949 tests failed
            <youpi> with the to-be-uploaded glibc
            <gg0> why does it coredump?
            <gg0> that's the test i had workarounded by increasing sleep from 1
              to 3 but i don't recall it coredump'ed
            <gg0> *recall if
            <gg0> "sleep 1" at bootstraptest/test_fork.rb:33
            <youpi> how can I run the test alone?

        IRC, OFTC, #debian-hurd, 2013-11-04:

            <youpi> gg0: ^
            <gg0> it should not take much
            <gg0> run $ make OPTS=-v test
            <gg0> found out how to minimize
            <gg0> mkdir _youpi && cp bootstraptest/{runner,test_fork}.rb _youpi
            <gg0> then run $ ./miniruby -I./lib -I. -I.ext/common
              ./tool/runruby.rb --extout=.ext  -- --disable-gems
              "./_youpi/runner.rb" --ruby="ruby2.0 -I./lib" -q -v
            <gg0> youpi: that should work
            <youpi> #1 test_fork.rb:1:in `<top (required)>': No such file or
              directory - /usr/src/ruby1.9.1-1.9.3.448/ruby2.0
              -I/usr/src/ruby1.9.1-1.9.3.448/lib -W0  bootstraptest.tmp.rb
              [ruby-dev:32404]
            <gg0> seems it can't find /usr/src/ruby1.9.1-1.9.3.448/ruby2.0
            <youpi> well it's ruby1.9.1 indeed :)
            <youpi> ok, got core
            <gg0> replace 2.0 with 1.9, check what you have in rootdir
            <gg0> k
            <youpi> Mmm, no, there's no core file
            <gg0> does stupidly increasing sleep time work?
            <youpi> nope
            <gg0> without *context it runs "make test" fine. real problems come
              later with "make test-all"
            <gg0> wrt test_fork, is correspondence between signals correct? i
              recall i read something about USR1 not implemented
            <youpi> USR1 is implemented, it's SIGRT which is not implemented
            <gg0> my next wild guess is that that has something to do with
              atfork, whatever that means
            <gg0> it makes 2 forks: one sleeps for 1 sec then kills -USR1
              itself, the second traps USR1 in getting current time. in the
              meanwhile parent sleeps for 2 secs

        IRC, OFTC, #debian-hurd, 2013-11-07:

            <gg0> ruby2.0 just built on unstable

        IRC, OFTC, #debian-hurd, 2013-11-09:

            <gg0> youpi: just found out a more "official" way to run one test
              only
              http://anonscm.debian.org/gitweb/?p=collab-maint/ruby1.9.1.git;a=blob;f=debian/README.porters;h=94aff7dd3ecd9f748498f2e285b4a4313b4b8f36;hb=HEAD
            <gg0> btw still getting coredumps?

        IRC, OFTC, #debian-hurd, 2013-11-13:

            <gg0> wrt the other test test_fork i suppose you made it not to
              segfault anymore, it simply does fail
            <youpi> I haven't taken any particular care
            <youpi> didn't have any time to deal with it

        IRC, OFTC, #debian-hurd, 2013-11-14:

            <gg0> btw patches to disable *context have been backported to 1.9
              as well so next 1.9 point release should have *context disabled
            <gg0> as 2.0 have
            <gg0> *has
            <gg0> i guess you'd like to get them reverted now
            <gg0> youpi: ^
            <youpi> after testing that *context work, yes

      * `sigaltstack`

        IRC, freenode, #hurd, 2013-10-09:

            <gnu_srs1> Hi, is sigaltstack() really supported, even if it is
              defined as well as SA_ONSTACK?
            <braunr> probably not
            <braunr> well,
            <braunr> i don't know actually, mistaking with something else
            <braunr> it may be supported
            <pinotree> iirc no
            <gnu_srs1> pinotree: are you sure?
            <pinotree> this is what i remember
            <pinotree> if you want to be sure that $foo works, just do the
              usual way: test it yourself
            <gnu_srs1> found it: hurd/TODO: *** does sigaltstack/sigstack
              really work? -- NO
            <pinotree> well TODO is old and there were signal-related patches
              by jk in the meanwhile, although i don't think they would have
              changed this lack
            <pinotree> in any case, test it
            <gnu_srs1> anybody fluent in assembly? Looks like this code
              destroys the stack: http://paste.debian.net/54331/
            <braunr> gnu_srs1: why would it ?
            <braunr> it does something special with the stack pointer but it
              just looks like it aligns it to 16 bytes, maybe because of sse2
              restrictions (recent gcc align the stack already anyway)
            <gnu_srs1> Well, in that case it is the called function:
              http://paste.debian.net/54341/
            <braunr> how do you know there is a problem with the stack in the
              first place ?
            <gnu_srs1> tracing up to here, everything is OK. then esp and ebp
              are destroyed.
            <gnu_srs1> and single stepping goes backward until it segfaults
            <braunr> "destroyed" ?
            <gnu_srs1> zero if I remember correctly now. the x86 version built
              for is i586, should that be changed to i486?
            <braunr> this shouldn't change anything
            <braunr> and they shouldn't get to 0
            <braunr> use gdb to determine exactly which instruction resets the
              stack pointer
            <gnu_srs1> how to step into the assembly part? using 's' steps
              through the function since no line information:
            <gnu_srs1> Single stepping until exit from function
              wine_call_on_stack,
            <gnu_srs1> which has no line number information.
            <braunr> gnu_srs1: use break on the address
            <gnu_srs1> how do i get the address of where the assembly starts?

      * <a id=recvmmsg>`recvmmsg`/`sendmmsg` (`t/sendmmsg`)</a>

        From [[!message-id "20120625233206.C000A2C06F@topped-with-meat.com"]],
        Roland McGrath: *They are generally useful interfaces and there is
        nothing intrinsically Linuxoid about them.  At least when not given a
        timeout, they could be implemented in terms of sendmsg/recvmsg.  So
        perhaps we ought to have a sysdeps/posix implementation that the Hurd
        would use instead of stubs (and folks can consider adding new RPCs).
        Then perhaps the Linux fallback case should be that instead of stubs,
        too.*

      * <a id=SOCK_CLOEXEC>`SOCK_CLOEXEC`</a>

        IRC, freenode, #hurd, 2013-09-02:

            <gnu_srs1> Do we support  accept4  with the SOCK_CLOEXEC flag?
            <gnu_srs1> According to the code in  sysdeps/mach/hurd/accept4.c
              that case is not covered 
            <gnu_srs1> (only O_NONBLOCK, not SOCK_NONBLOCK??))
            <pinotree> gnu_srs1: we do
            <pinotree> but only for accept4, not for socket and socketpair
            <gnu_srs1> pinotree: cannot find the case for O_CLOEXEC covered in
              __libc_accept4()
            <pinotree> gnu_srs1: no, you need SOCK_*
            <gnu_srs1> The only code for accept4() is in sysdeps/mach/hurd/ and
              it uses O_* for flags ?
            <pinotree>   flags = sock_to_o_flags (flags);
            <pinotree> tried checking it?
            <gnu_srs1> Aha, tks:-D
            <pinotree> and you don't need an explicit case of O_CLOEXEC, since
              it is handled in other ways

        [[!message-id "1378154151.21738.15.camel@G3620.my.own.domain"]].

        IRC, freenode, #hurd, 2013-09-03:

            <gnu_srs> any ideas about the SOCK_CLOEXEC issue?
            <pinotree> didn't i tell already about it?
            <gnu_srs> I did not find any hurd related code in tschwinges
              branches.
            <pinotree> you didn't check deep then...
            <gnu_srs> so why does socket/socketpair not return ENOSYS then?
            <pinotree> why should it, since they are implemented?
            <braunr> ...
            <gnu_srs> for socket/socketpair?
            <braunr> gnu_srs: enosys means no system call
            <gnu_srs> s/ENOSYS/EINVAL/
            <gnu_srs> see the mail to the bug-hurd/debian-hurd ML for more info
            <gnu_srs> and tschwinges reply
            <pinotree> which is what i knew already?
            <gnu_srs> pinotree: please reply on the mailing list on the EINVAL
              vs EPROTOTYPE issue to clarify things
            <pinotree> gnu_srs:
              https://sourceware.org/ml/libc-alpha/2013-02/msg00092.html
            <pinotree> gnu_srs: things were clear already...
            <gnu_srs> pinotree: I've read that patch and still pflocal/pf.c
              returns EPROTOTYPE not changed by the __socket wrapper in eglibc
            <pinotree> gnu_srs: what about realizing SOCK_CLOEXEC and friends
              are NOT posix?
            <gnu_srs> since socket/socketpair does not return EINVAL the dbus
              code has to be patched then?
            <pinotree> pflocal should never ever get such flags mixed to the
              protocol, so any invalid value of protocol correctly returns
              EPROTOTYPE
            <gnu_srs> this is the question I need answered: Which way to go?
            <pinotree> all of them
            <gnu_srs> ?
            <pinotree> - applications should not assume that because you have
              accept4 (which is not posix) then SOCK_CLOEXEC and SOCK_NONBLOCK
              (flags for it) are usable to socket and socketpair
            <pinotree> - glibc should (as the idea of my patch) handle
              implementations providing SOCK_* but not supporting them for
              socket/socketpair
            <pinotree> - finally the hurd part of glibc could implement them
            <gnu_srs> to conclude: should I send a bug report for dbus then?
            <gnu_srs> pinotree: yes or no?
            <pinotree> gnu_srs: *shrug* i wrote it above, so an *upstream*
              report (not a debian one)

        IRC, freenode, #hurd, 2013-09-06:

            <gnu_srs> I've found another error code issue, now in  glib2.0 (and
              dbus). Are you really sure the error code 
            <gnu_srs> for protocol of pflocal/pf.c should be
              EPROTONOSUPPORT. The code expects EINVAL for a protocol with
            <gnu_srs>  SOCK_CLOEXEC, which is a flag. Maybe pf.c should add
              this case and return EINVAL instead of 
            <gnu_srs> submitting bug reports upstream. Yes, I know this is not
              POSIX, but it is defined for Hurd too, 
            <gnu_srs> currently only supported for accept4, not socket or
              socketpair. 
            <pinotree> gnu_srs: no, and i explained already why it is wrong
              this way
            <pinotree> pflocal shouldn't even get such flags
            <pinotree> (pflocal or any other server implementing socket_create)
            <gnu_srs> (20:19:35) pinotree: pflocal shouldn't even get such
              flags
            <gnu_srs> then the glibc wrapper code is missing to catch this
              flag:(
            <gnu_srs> youpi: ?
            <pinotree> gnu_srs: because, as told many times, socket and
              socketpair do not support such flags
            <pinotree> given they don't do, they filter nothing
            <pinotree> and no, you need to file bugs upstream, since having
              SOCK_* and accept4 does not imply at all that socket and
              socketpair support them

        IRC, freenode, #hurd, 2013-09-07:

            <gnu_srs> A correction from yesterdays discussion:
              s/EPROTONOSUPPORT/EPROTOTYPE

        IRC, freenode, #hurd, 2013-09-10:

            <gnu_srs> for dbus2.0 I found out that the third SOCK_CLOEXEC case
              needs a patch too (more working tests),
            <gnu_srs> the updated patch is at http://paste.debian.net/37948/ if
              you have the time, otherwise I'll do it.
            <pinotree> gnu_srs: which is what i wrote in my bug report...
            <gnu_srs> Yes you wrote that, but the patch is not updated yet?
            <pinotree> it refers to a different socket access, recently added,
              which is not used by default
            <gnu_srs> I got two more tests running when adding that patch:-/
            <pinotree> tests of what?
            <gnu_srs>  run-test.sh and run-test-systemserver.sh:P
            <pinotree> tests of what?
            <pinotree> i don't have the universal knowledge of the files in all
              the sources
            <gnu_srs> dbus-1.6.14/test/name-test/*

        [[!message-id "523A3D6C.2030200@gmx.de"]].

        IRC, OFTC, #debian-hurd, 2013-09-19:

            <pinotree> tschwinge: ehm, regarding the SOCK_* patches for
              socket/socketpair, didn't we talk about them when i worked on
              eglibc 2.17?

      * `mlock`, `munlock`, `mlockall`, `munlockall`

        IRC, freenode, #hurd, 2014-01-09:

            <gnu_srs> Hi, is mlock, mlockall et al implemented?
            <braunr> i doubt it
            <braunr> mlock could be, but mlockall only partially

      * [[service_solahart_jakarta_selatan__082122541663/Glibc_ioctls]]

      * Support for `$ORIGIN` in the dynamic linker, `ld.so`

        IRC, freenode, #hurd, 2014-02-23:

            <sjamaan>
              https://www.gnu.org/software/hurd/user/jkoenig/java/report.html
              says $ORIGIN patches have been added to Hurd.  Have those hit the
              mainline codebase?

        [[user/jkoenig/java]], [[user/jkoenig/java/report]].

            <sjamaan> It doesn't seem to work here, but perhaps I'm missing
              something (I'm using the prebuilt Debian/Hurd 2014-02-11 VM
              image)
            <sjamaan> objdump -x says the value of RPATH is $ORIGIN
            <sjamaan> But it doesn't load a library I placed in the same dir as
              the binary
            <braunr> sjamaan: i'm not sure
            <braunr> sjamaan: what are you trying to do ?

        IRC, freenode, #hurd, 2014-02-24:

            <sjamaan> braunr: I am working on a release of the CHICKEN Scheme
              compiler. Its test suite is currently failing on the stand-alone
              deployment tests.  Either it should work and use $ORIGIN, or the
              test should be disabled, saying Hurd is not supported for
              stand-alone deployment-directories
            <sjamaan> braunr: The basic idea is to be able to create "appdirs"
              like on OS X or PC-BSD, containing all the dependencies a program
              needs, which can then simply be untarred
            <braunr> sjamaan: ok so you do need $ORIGIN
            <sjamaan> yeah
            <sjamaan> iiuc, so does Java.  Does Java work on Hurd?
            <braunr> we had packages at the time jkoenig worked on it
            <braunr> integration of patches may have been incomplete, i wasn't
              there at the time and i'm not sure
            <sjamaan> So it's safest to claim it's unsupported, for now?
            <braunr> yes
            <sjamaan> Thank you, I'll do that and revisit it later

      * `mig_reply_setup`

        IRC, freenode, #hurd, 2014-02-24:

            <teythoon> braunr: neither hurd, gnu mach or glibc provides
              mig_reply_setup
            <teythoon> i want to provide this function, where should i put it ?
            <teythoon> i found some mach source that put it in libmach afaic
            <teythoon>
              ftp://ftp.sra.co.jp/.a/pub/os/mach/extracted/mach3/mk/user/libmach/mig_reply_setup.c
            <braunr> teythoon: what does it do ?
            <teythoon> braunr: not much, it just initializes the reply message
            <teythoon> libports does this as well, in the
              ports_manage_port_operations* functions
            <braunr> teythoon: is it a new function you're adding ?
            <teythoon> braunr: yes
            <teythoon> braunr: glibc has a declaration for it, but no
              implementation
            <braunr> teythoon: i think it should be in glibc
            <braunr> maybe in mach/

      * [[POSIX file record locking|file_locking]]

      * <a name="execve_relative_paths">`execve` with relative paths</a>

        [[!GNU_Savannah_bug 28934]], [[user/pochu]], [[!message-id
        "4BFA500A.7030502@gmail.com"]].

        IRC, freenode, #hurd, 2014-03-05:

            <teythoon> youpi: what about the exec_filename patch series? [...]
            <youpi> Roland was disagreeing with it

      * <a name="mount">`mount`/`umount`</a>

        IRC, freenode, #hurd, 2014-03-01:

            <gnu_srs1> Hi, how to handle packages depending on mount.h, et al?
              On Hurd mount/umount is supplied by hurd is not in libc?
            <azeem> gnu_srs1: mount or mount.h?
            <gnu_srs1> mount.h et al
            <gnu_srs1> man 2 mount
            <azeem> what is the question then?
            <gnu_srs1> some packages expect the mount 2 functionality
              available, not by the external command mount/umonut
            <gnu_srs1> umount*
            <gnu_srs1> azeem: one example is fuse
            <teythoon> gnu_srs1: that is correct
            <teythoon> gnu_srs1: i put a small hacks entry in the list about
              moving the mount/umount functionality from our utilities to the
              libc

      * <a name="posix_timers">POSIX Timers</a>

        `timer_create`, `timer_delete`, [[`clock_gettime`|service_solahart_jakarta_selatan__082122541663/clock_gettime]], and
        so on.

    For specific packages:

      * <a id=octave>[[service_solahart_jakarta_selatan__082122541663/glibc/octave]]</a>

  * <a id=t_cleanup_kernel-features.h>Create `t/cleanup_kernel-features.h`.</a>

  * <a id=Secure_file_descriptor_handling>[[service_solahart_jakarta_selatan__082122541663/Secure_file_descriptor_handling]].</a>

  * <a id=sendfile>In `sysdeps/unix/sysv/linux/Makefile`, there are a bunch of
    `-DHAVE_SENDFILE` -- but we do have `sendfile`, too.</a>

    Define `__ASSUME_SENDFILE` to 1 in `kernel-features.h`, if `sendfile`
    works.

  * <a id=pthreadoverwrite>`/usr/include/pthread.h` overwrite issue</a>

    `make`, after editing `nss/nss_db/db-initgroups.c`:

        [...]
        make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/resolv'
        make  subdir=nss -C nss ..=../ others
        make[2]: Entering directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss'
        /usr/bin/install -c -m 644 ../include/pthread.h /usr/include/pthread.h
        /usr/bin/install: cannot remove `/usr/include/pthread.h': Permission denied
        make[2]: *** [/usr/include/pthread.h] Error 1
        make[2]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker/nss'
        make[1]: *** [nss/others] Error 2
        make[1]: Leaving directory `/media/erich/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker'
        make: *** [all] Error 2

    See [[!message-id "871uv99c59.fsf@kepler.schwinge.homeip.net"]].  Passing
    `install_root=/INVALID` to `make`/`make check` is a cheap cure.  For `make
    install`, prepending an additional slash to `install_root` (that is,
    `install_root=//[...]`) is enough to obfuscate the Makefile rules.

  * <a id=syslog.c>`sysdeps/unix/sysv/linux/syslog.c`</a>

  * <a id=fsync>`fsync` on a pipe</a>

    IRC, freenode, #hurd, 2012-08-21:

        <braunr> pinotree: i think gnu_srs spotted a conformance problem in
          glibc
        <pinotree> (only one?)
        <braunr> pinotree: namely, fsync on a pipe (which is actually a
          socketpair) doesn't return EINVAL when the "operation not supported"
          error is returned as a "bad request message ID"
        <braunr> pinotree: what do you think of this case ?
        <pinotree> i'm far from an expert on such stuff, but seems a proper E*
          should be returned
        <braunr> (there also is a problem in clisp falling in an infinite loop
          when trying to handle this, since it uses fsync inside the error
          handling code, eww, but we don't care :p)
        <braunr> basically, here is what clisp does
        <braunr> if fsync fails, and the error isn't EINVAL, let's report the
          error
        <braunr> and reporting the error in turn writes something on the
          output/error stream, which in turn calls fsync again
        <pinotree> smart
        <braunr> after the stack is exhausted, clisp happily crashes
        <braunr> gnu_srs: i'll alter the clisp code a bit so it knows about our
          mig specific error
        <braunr> if that's the problem (which i strongly suspect), the solution
          will be to add an error conversion for fsync so that it returns
          EINVAL
        <braunr> if pinotree is willing to do that, he'll be the only one
          suffering from the dangers of sending stuff to the glibc maintainers
          :p
        <pinotree> that shouldn't be an issue i think, there are other glibc
          hurd implementations that do such checks
        <gnu_srs> does fsync return EINVAL for other OSes?
        <braunr>        EROFS, EINVAL
        <braunr>               fd is bound to a special file which does not
          support synchronization.
        <braunr> obviously, pipes and sockets don't
        <pinotree>
          http://pubs.opengroup.org/onlinepubs/9699919799/functions/fsync.html
        <braunr> so yes, other OSes do just that
        <pinotree> now that you speak about it, it could be the failure that
          the gnulib fsync+fdatasync testcase have when being run with `make
          check` (although not when running as ./test-foo)
        <braunr> hm we may not need change glibc
        <braunr> clisp has a part where it defines a macro IS_EINVAL which is
          system specific
        <braunr> (but we should change it in glibc for conformance anyway)
        <braunr> #elif defined(UNIX_DARWIN) || defined(UNIX_FREEBSD) ||
          defined(UNIX_NETBSD) || defined(UNIX_OPENBSD) #define IS_EINVAL_EXTRA
          ((errno==EOPNOTSUPP)||(errno==ENOTSUP)||(errno==ENODEV))
        <pinotree> i'd rather add nothing to clisp
        <braunr> let's see what posix says
        <braunr> EINVAL
        <braunr> so right, we should simply convert it in glibc
        <gnu_srs> man fsync mentions EINVAL
        <braunr> man pages aren't posix, even if they are usually close
        <gnu_srs> aha
        <pinotree> i think checking for MIG_BAD_ID and EOPNOTSUPP (like other
          parts do) will b enough
        <pinotree> *be
        <braunr> gnu_srs: there, it finished correctly even when piped
        <gnu_srs> I saw that, congrats!
        <braunr> clisp is quite tricky to debug
        <braunr> i never had to deal with a program that installs break points
          and handles segfaults itself in order to implement growing stacks :p
        <braunr> i suppose most interpreters do that
        <gnu_srs> So the permanent change will be in glibc, not clisp?
        <braunr> yes

    IRC, freenode, #hurd, 2012-08-24:

        <gnu_srs1> pinotree: The changes needed for fsync.c is at
          http://paste.debian.net/185379/ if you want to try it out (confirmed
          with rbraun)
        <youpi> I agree with the patch, posix indeed documents einval as the
          "proper"  error value
        <pinotree> there's fdatasync too
        <pinotree> other places use MIG_BAD_ID instead of EMIG_BAD_ID
        <braunr> pinotree: i assume that if you're telling us, it's because
          they have different values
        <pinotree> braunr: tbh i never seen the E version, and everywhere in
          glibc the non-E version is used
        <gnu_srs1> in sysdeps/mach/hurd/bits/errno.h only the E version is
          defined
        <pinotree> look in gnumach/include/mach/mig_errors.h
        <pinotree> (as the comment in errno.h say)
        <gnu_srs1> mig_errors.h yes. Which comment: from errors.h: /* Errors
          from <mach/mig_errors.h>.  */ and then the EMIG_ stuff?
        <gnu_srs1> Which one is used when building libc?
        <gnu_srs1> Answer: At least in fsync.c errno.h is used: #include
          <errno.h>
        <gnu_srs1> Yes, fdatasync.c should be patched too.
        <gnu_srs1> pinotree: You are right: EMIG_ or MIG_ is confusing. 
        <gnu_srs1> /usr/include/i386-gnu/bits/errno.h:     /* Errors from
          <mach/mig_errors.h>.  */
        <gnu_srs1> /usr/include/hurd.h:#include <mach/mig_errors.h>

    IRC, freenode, #hurd, 2012-09-02:

        <antrik> braunr: regarding fsync(), I agree that EOPNOTSUPP probably
          should be translated to EINVAL, if that's what POSIX says. it does
          *not* sound right to translate MIG_BAD_ID though. the server should
          explicitly return EOPNOTSUPP, and that's what the default trivfs stub
          does. if you actually do see MIG_BAD_ID, there must be some other
          bug...
        <braunr> antrik: right, pflocal doesn't call the trivfs stub for socket
          objects
        <braunr> trivfs_demuxer is only called by the pflocal node demuxer, for
          socket objects it's another call, and i don't think it's the right
          thing to call trivfs_demuxer there either
        <pinotree> handling MAG_BAD_ID isn't a bad idea anyway, you never know
          what the underlying server actually implements
        <pinotree> (imho)
        <braunr> for me, a bad id is the same as a not supported operation
        <pinotree> ditto
        <pinotree> from fsync's POV, both the results are the same anyway, ie
          that the server does not support a file_sync operation
        <antrik> no, a bad ID means the server doesn't implement the protocol
          (or not properly at least)
        <antrik> it's usually a bug IMHO
        <antrik> there is a reason we have EOPNOTSUPP for operations that are
          part of a protocol but not implemented by a particular server
        <pinotree> antrik: even if it could be the case, there's no reason to
          make fsync fail anyway
        <antrik> pinotree: I think there is. it indicates a bug, which should
          not be hidden
        <pinotree> well, patches welcome then...
        <antrik> thing is, if sock objects are actually not supposed to
          implement the file interface, glibc shouldn't even *try* to call
          fsync on them
        <pinotree> how?
        <pinotree> i mean, can you check whether the file interface is not
          implemented, without doing a roundtrip^
        <pinotree> ?
        <antrik> well, the sock objects are not files, i.e. they were *not*
          obtained by file_name_lookup(), but rather a specific call. so glibc
          actually *knows* that they are not files.
        <braunr> antrik: this way of thinking means we need an "fd" protocol
        <braunr> so that objects accessed through a file descriptor implement
          all fd calls
        <antrik> now I wonder though whether there are conceivable use cases
          where it would make sense for objects obtained through the socket
          call to optionally implement the file interface...
        <antrik> which could actually make sense, if libc lets through other
          file calls as well (which I guess it does, if the sock ports are
          wrapped in normal fd structures?)
        <braunr> antrik: they are
        <braunr> and i'd personally be in favor of such an fd protocol, even if
          it means implementing stubs for many useless calls
        <braunr> but the way things are now suggest a bad id really means an
          operation is simply not supported
        <antrik> the question in this case is whether we should make the file
          protocol mandatory for anything that can end up in an FD; or whether
          we should keep it optional, and add the MIG_BAD_ID calls to *all* FD
          operations
        <antrik> (there is no reason for fsync to be special in this regard)
        <braunr> yes
        <antrik> braunr: BTW, I'm rather undecided whether the right approach
          is a) requiring an FD interface collection, b) always checking
          MIG_BAD_ID, or perhaps c) think about introducing a mechanism to
          explicitly query supported interfaces...

    IRC, freenode, #hurd, 2012-09-03:

        <braunr> antrik: querying interfaces sounds like an additional penalty
          on performance
        <antrik> braunr: the query usually has to be done only once. in fact it
          could be integrated into the name lookup...
        <braunr> antrik: once for every object
        <braunr> antrik: yes, along with the lookup would be a nice thing

    [[!message-id "1351231423.8019.19.camel@hp.my.own.domain"]].

  * <a id=t_no-hp-timing>`t/no-hp-timing`</a>

    IRC, freenode, #hurd, 2012-11-16

        <pinotree> tschwinge: wrt the glibc topgit branch t/no-hp-timing,
          couldn't that file be just replaced by #include
          <sysdeps/generic/hp-timing.h>?

  * <a id=flockfile>`flockfile`/`ftrylockfile`/`funlockfile`</a>

    IRC, freenode, #hurd, 2012-11-16

        <pinotree> youpi: uhm, in glibc we use
          stdio-common/f{,try,un}lockfile.c, which do nothing (as opposed to eg
          the nptl versions, which do lock/trylock/unlock); do you know more
          about them?
        <youpi> pinotree: ouch
        <youpi> no, I don't know
        <youpi> well, I do know what they're supposed to do
        <pinotree> i'm trying fillig them, let's see
        <youpi> but not why we don't have them
        <youpi> (except that libpthread is "recent")
        <youpi> yet another reason to build libpthread in glibc, btw
        <youpi> oh, but we do provide lockfile in libpthread, don't we ?
        <youpi> pinotree: yes, and libc has weak variants, so the libpthread
          will take over
        <pinotree> youpi: sure, but that in stuff linking to pthreads
        <pinotree> if you do a simple application doing eg main() { fopen +
          fwrite + fclose }, you get no locking
        <youpi> so?
        <youpi> if you don't have threads, you don't need locks :)
        <pinotree> ... unless there is some indirect recursion
        <youpi> ?
        <pinotree> basically, i was debugging why glibc tests with mtrace() and
          ending with muntrace() would die (while tests without muntrace call
          wouldn't)
        <youpi> well, I still don't see what a lock will bring
        <pinotree> if you look at the muntrace implementation (in
          malloc/mtrace.c), basically fclose can trigger a malloc hook (because
          of the free for the FILE*)
        <youpi> either you have threads, and it's need, or you don't, and it's
          a nop
        <youpi> yes, and ?
        <braunr> does the signal thread count ?
        <youpi> again, in linux, when you don't have threads, the lock is a nop
        <youpi> does the signal thread use IO ?
        <braunr> that's the question :)
        <braunr> i hope not
        <youpi> IIRC the signal thread just manages signals, and doesn't
          execute the handler itself
        <braunr> sure
        <braunr> i was more thinking about debug stuff
        <youpi> can't hurt to add them anyway, but let me still doubt that it'd
          fix muntrace, I don't see why it would, unless you have threads
        <pinotree> that's what i'm going next
        <pinotree> pardon, it seems i got confused a bit
        <pinotree> it'd look like a genuine muntrace bug (muntrace → fclose →
          free hook → lock lock → fprint (since the FILE is still set) → malloc
          → malloc hook → lock lock → spin)
        <pinotree> at least i got some light over the flockfile stuff, thanks
          ;)
        <pinotree> youpi: otoh, __libc_lock_lock (etc) are noop in the base
          implementation, while doing real locks on hurd in any case, and on
          linux only if nptl is loaded, it seems
        <pinotree> that would explain why on linux you get no deadlock
        <youpi> unless using nptl, that is?
        <pinotree> hm no, even with pthread it works
        <pinotree> but hey, at least the affected glibc test now passes
        <pinotree> will maybe try to do investigation on why it works on linux
          tomorrow

    [[!message-id "201211172058.21035.toscano.pino@tiscali.it"]].

    In context of [[service_solahart_jakarta_selatan__082122541663/libpthread]].

    IRC, freenode, #hurd, 2013-01-21

        <braunr> ah, found something interesting
        <braunr> tschwinge: there seems to be a race on our file descriptors
        <braunr> the content written by one thread seems to be retained
          somewhere and another thread writing data to the file descriptor will
          resend what the first already did
        <braunr> it could be a FILE race instead of fd one though
        <braunr> yes, it's not at the fd level, it's above
        <braunr> so good news, seems like the low level message/signalling code
          isn't faulty here
        <braunr> all right, simple explanation: our IO_lockfile functions are
          no-ops
        <pinotree> braunr: i found that out days ago, and samuel said they were
          okay
        <braunr> well, they're not no-ops in libpthreads
        <braunr> so i suppose they replace the default libc stubs, yes
        <pinotree> so the issue happens in cthreads-using apps?
        <braunr> no
        <braunr> we don't have cthreads apps any more
        <braunr> and aiui, libpthreads provides cthreads compatibility calls to
          libc, so everything is actually using pthreads
        <braunr> more buffer management debugging needed :/
        <pinotree> hm, so how can it be that there's a multithread app with no
          libpthread-provided file locking?
        <braunr> ?
        <braunr> file locking looks fine
        <braunr> hm, the recursive locking might be wrong though
        <braunr> ./sysdeps/mach/hurd/bits/libc-lock.h:#define
          __libc_lock_owner_self() ((void *) __hurd_threadvar_location (0))
        <braunr> nop, looks fine too
        <braunr> indeed, without stream buffering, the problem seems to go away
        <braunr> pinotree: it really looks like the stub IO_flockfile is used
        <braunr> i'll try to make sure it's the root of the problem
        <pinotree> braunr: you earlier said that there's some race with
          different threads, no?
        <braunr> yes
        <braunr> either a race or an error in the iostream management code
        <braunr> but i highly doubt the latter
        <pinotree> if the stub locks are used, then libpthread is not
          loaded... so which different threads are running?
        <braunr> that's the thing
        <braunr> the libpthread versions should be used
        <pinotree> so the application is linked to pthread?
        <braunr> yes
        <pinotree> i see, that was the detail i was missing earlier
        <braunr> the common code looks fine, but i can see wrong values even
          there
        <braunr> e.g. when vfprintf calls write, the buffer is already wrong
        <braunr> i've made similar tests on linux sid, and it behaves as it
          should
        <pinotree> hm
        <braunr> i even used load to "slow down" my test program so that
          preemption is much more likely to happen
        <pinotree> note we have slightly different behaviour in glibc's libio,
          ie different memory allocation ways (mmap on linux, malloc for us)
        <braunr> the problem gets systematic on the hurd while it never occurs
          on linux
        <braunr> that shouldn't matter either
        <pinotree> ok
        <braunr> but i'll make sure it doesn't anyway
        <braunr> this mach_print system call is proving very handy :)
        <braunr> and also, with load, unbuffered output is always correct too
        <pinotree> braunr: you could try the following hack
          http://paste.debian.net/227106/
        <braunr> what does it do ?
        <pinotree> (yes, ugly as f**k)
        <braunr> does it force libio to use mmap ?
        <braunr> or rather, enable ?
        <pinotree> provides a EXEC_PAGESIZE define in libio, so it makes it use
          mmap (like on linux) instead of malloc

  * <a id=t_pagesize>`t/pagesize`.</a>

        <braunr> yes, the stub is used instead of the libpthreads code
        <braunr> tschwinge: ^
        <braunr> i'll override those to check that it fixes the problem
        <braunr> hm, not that easy actually
        <pinotree> copy their files from libpthreads to sysdeps/mach/hurd
        <pinotree> hm right, in libpthread they are not that split as in glibc
        <braunr> let's check symbol declaration to understand why the stubs
          aren't overriden by ld
        <braunr> _IO_vfprintf correctly calls @plt versions
        <braunr> i don't know enough about dynamic linking to see what causes
          the problem :/
        <braunr> youpi: it seems our stdio functions use the stub IO_flockfile
          functions
        <youpi> really? I thought we were going through cthreads-compat.c
        <braunr> yes really
        <braunr> i don't know why, but that's the origin of the "duplicated"
          messages issue
        <braunr> messages aren't duplicated, there is a race that makes on
          thread reuse the content of the stream buffer
        <braunr> one*
        <youpi> k, quite bad
        <braunr> at least we know where the problem comes from now
        <braunr> youpi: what would be the most likely reason why weak symbols
          in libc wouldn't be overriden by global ones from libpthread ?
        <youpi> being loaded after libc
        <braunr> i tried preloading it
        <braunr> i'll compare with what is done on wheezy
        <youpi> you have the local-dl-dynamic-weak.diff patch, right?
        <braunr> (on squeeze, the _IO_flockfile function in libc seems to do
          real work unlike our noop stub)
        <braunr> it's the debian package, i have all patches provided there
        <braunr> indeed, on linux, libc provides valid IO_flock functions
        <braunr> ./sysdeps/pthread/flockfile.c:strong_alias (__flockfile,
          _IO_flockfile)
        <braunr> that's how ntpl exports it
        <braunr> nptl*
        <pinotree> imho we should restructure libpthread to be more close to
          nptl
        <braunr> i wish i knew what it involves
        <pinotree> file structing for sources and tests, for example
        <braunr> well yes obviously :)
        <braunr> i've just found a patch that does exactly that for linuxthreads
        <pinotree> that = fix the file locking?
        <braunr> in addition to linuxthreads/lockfile.c (which we also
          equivalently provide), there is
          linuxthreads/sysdeps/pthread/flockfile.c
        <braunr> no, restructiring
        <braunr> restructuring*
        <braunr> i still have only a very limited idea of how the glibc sources
          are organized
        <pinotree> the latter is used as source file when compiling flockfile.c
          in stdio-common
        <braunr> shouldn't we provide one too ?
        <pinotree> that would mean it would be compiled as part of libc proper,
          not libpthread
        <braunr> yes
        <braunr> that's what both linuxthreads and nptl seem to do
        <braunr> and the code is strictly the same, i.e. a call to the internal
          _IO_lock_xxx functions
        <youpi> I guess that's for the hot-dlopen case
        <youpi> you need to have locks properly taken at dlopen time
        <braunr> youpi: do you mean adding an flockfile.c file to our sysdeps
          will only solve the problem by side effect ?
        <braunr> and that the real problem is that the libpthread versions
          aren't used ?
        <youpi>  yes
        <braunr> ok
        <braunr> youpi: could it simply be a versioning issue ?
        <youpi> could be
        <braunr> it seems so
        <braunr> i've rebuilt with the flockfile functions versioned to 2.2.6
          (same as in libc) and the cthreads_compat functions are now used
        <braunr> and the problem doesn't occur any more with my test code
        <braunr> :)
        <youpi> could you post a patch?
        <braunr> i need a few info before
        <youpi> it'd be good to check which such functions are hooked
        <braunr> i suppose the version for functions declared in libpthreads
          shouldn't change, right ?
        <youpi> yes
        <braunr> ok
        <youpi> they didn't have a vresion before
        <braunr> shall i commit directly ?
        <youpi> so it should be fine
        <braunr> well, they did
        <braunr> 2.12
        <youpi> yes, but please tell me when it's done
        <braunr> sure
        <youpi> so I can commit that to debian's eglibc
        <youpi> I mean, before we integrated libpthread build into glibc
        <youpi> so they never had any version before 2.12
        <braunr> ok
        <youpi> basically we need to check the symbols which are both in
          libpthread and referenced in libc
        <youpi> to make sure they have the same version in the reference
        <braunr> ok
        <youpi> only weak references need to be checked, others would have
          produced a runtime error
        <braunr> youpi: done
        <braunr> arg, the version i mention in the comment is wrong
        <braunr> i suppose people understand nonetheless
        <youpi> probably, yes
        <braunr> ah, i can now appreciate the headache this bug hunting gave me
          these last days :)

    IRC, freenode, #hurd, 2013-01-22

        <youpi> braunr: commited to debian glibc
        <youpi> btw, it's normal that the program doesn't terminate, right?
        <youpi> (i.e. it's the original bug you were chasing)
        <braunr> youpi: about your earlier question (yesterday) about my test
          code, it's expected to block, which is the problem i was initially
          working on
        <youpi> ok, so all god
        <youpi> +o

  * <a id=t_pagesize2>`t/pagesize`</a>

    IRC, freenode, #hurd, 2012-11-16

        <pinotree> tschwinge: somehow related to your t/pagesize branch: due to
          the fact that EXEC_PAGESIZE is not defined on hurd, libio/libioP.h
          switches the allocation modes from mmap to malloc

    [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]].

    IRC, freenode, #hurd, 2013-01-21

        <braunr> why is it a hack ?
        <pinotree> because most probably glibc shouldn't rely on EXEC_PAGESIZE
          like that
        <braunr> ah
        <pinotree> there's a mail from roland, replying to thomas about this
          issue, that this use of EXEC_PAGESIZE to enable mmap or not is just
          wrong
        <braunr> ok
        <pinotree> (the above is
          http://thread.gmane.org/87mxd9hl2n.fsf@kepler.schwinge.homeip.net )
        <braunr> thanks
        <pinotree> (just added the reference to that in the wiki)
        <braunr> pinotree: btw, what's wrong with using malloc instead of mmap
          in libio ?
        <pinotree> braunr: i'm still not totally sure, most probably it should
          be slightly slower currently
        <braunr> locking contention ?
        <braunr> pinotree:
          http://www.sourceware.org/ml/libc-alpha/2006-11/msg00061.html
        <braunr> pinotree: it looks to me there is now no valid reason not to
          use malloc
        <braunr> the best argument for mmap is that libio requires zeroed
          memory, but as the OP says, zeroing a page is usually more expensive
          than a small calloc (even on kernel that keep a list of zeroed pages
          for quick allocations, frequent mmaps() often make this list empty)
        <pinotree> braunr: mmap allocations in libio are rounded to the page
          size
        <braunr> well they have to

  * <a id=LD_DEBUG>`LD_DEBUG`</a>

    IRC, freenode, #hurd, 2012-11-22

        <pinotree> woot, `LD_DEBUG=libs /bin/ls >/dev/null` prints stuff and
          then sigsegv
        <tschwinge> Yeah, that's known for years...  :-D
        <tschwinge> Probably not too difficult to resolve, though.

  * IRC, OFTC, #debian-hurd, 2013-08-16:

        <pinotree> http://paste.debian.net/25934/ ← _hurd_thread_sigstate calls
          malloc, boom

  * <a id=conformtest>`conformtest`</a>

    IRC, OFTC, #debian-hurd, 2013-09-22:

        <youpi> btw, I noticed that glibc has a head conformance test which we
          happily fail quite a bit :)
        <youpi> it's not so awful, we don't have twice as many failures as
          linux, but not so far
        <pinotree> youpi: do you mean "header" for "head", right?
        <youpi> err, where ? :)
        <pinotree> <youpi> btw, I noticed that glibc has a head conformance
          test which we happily fail quite a bit :)
        <youpi> ah, yes
        <pinotree> noticed that too
        <youpi> I had a quick look at the POSIX part, some things are probably
          not too hard to change (e.g. exposing pthread_kill in signal.h)
        <youpi> others will by quite hard to fix (short type instead of int
          type for some flock structure field)
        <youpi> s/by/be/

  * `truncate`/`ftruncate`

    Hurd fixed with 2013-10-03 commit 6c3825f2b750bf9b913c6ea986739e648c470603,
    glibc still to be done?

    IRC, freenode, #hurd, 2013-10-01:

        <pinotree> libdiskfs/node-drop.c:      assert (np->dn_stat.st_size == 0); ←
          this one?
        <pinotree> iirc you constantly get that when building ustr
        <braunr> is ustr a package ?
        <pinotree> yes
        <pinotree> iirc the ustr tests are mostly disk-intensive

    IRC, freenode, #hurd, 2013-10-02:

        <braunr> i've traced the problem up to truncate
        <braunr> which gets a negative size
        <braunr> shouldn't take long to find out where it comes from now
        <pinotree> it seems our truncate doesn't handle negative values well though
        <braunr>        EINVAL The argument length is negative or larger than the
          maximum file size.
        <braunr> i still have to see whether it comes from the user (unlikely) or
          if it's an internal inconsistency
        <braunr> i suspect some code wrongly handles vm_map failures
        <braunr> leading to that inconsistency
        <braunr> pinotree: looks like glibc doesn't check for length >= 0
        <pinotree> yeah
        <braunr> servers should do it nonetheless
        <pinotree> should we fix glibc, libdiskfs/libnetfs/libtrivfs/etc, or both?
        <braunr> it appears a client does the truncate
        <braunr> i'd say both
        <braunr> can you take the glibc part ? :)
        <pinotree> i was going to do the hurd part... :p
        <pinotree> ok, i'll pick libc
        <braunr> well i'm doing it already
        <braunr> i want to write a test case first
        <braunr> to make sure that's the problem
        <pinotree> already on the hurd part, you mean?
        <braunr> yes
        <pinotree> ok
        <braunr> ok looks like it
        <braunr> i can't reproduce the assertion but it does make ext2fs freeze
        <braunr> pinotree: http://darnassus.sceen.net/~rbraun/test_ftruncate.c
        <pinotree> merci
        <braunr> pinotree: ustr builds
        <pinotree> wow
        <braunr> the client code (ustr) seems to perform a ftruncate with size
          ((size_t)-1) whereas lengths are signed ..
        <braunr> i'll check other libraries and send a patch soon

    IRC, freenode, #hurd, 2013-10-03:

        <braunr> youpi: i've committed a fix to hurd that checks for negative sizes
          when truncating files
        <braunr> this allows building the ustr package without making ext2fs choke
          on an assertion
        <braunr> pinotree is preparing a patch for glibc
        <braunr> see truncate/ftruncate
        <braunr> with an off_t size parameter, which can be negative
        <braunr>        EINVAL The argument length is negative or larger than the
          maximum file size.
        <braunr> hurd servers were not conforming to that before my change

  * `t/ptrmangle`: `PTR_MANGLE`/`PTR_DEMANGLE`

      * <https://sourceware.org/glibc/wiki/PointerEncryption>

      * See also [[t/tls|service_solahart_jakarta_selatan__082122541663/glibc/t/tls]].

      * b7f2d27dbd85f6a0966dc389ad4f8205085b7ae8 `ARM: Add pointer encryption
        support.` may help to find all the places that need to be touched when
        adding support.

  * <a id=baselinechanges>Verify baseline changes, if we need any follow-up changes:</a>

      * a11ec63713ea3903c482dc907a108be404191a02
      * 7e2b0c8562b35155820f87b5ff02a8b6850344cc
      * 8c0677fe5d91b7269364ca08fa08ed09e4c2d8c9
      * 5a2a1d75043138e696222ced4560de2fb90b8024
      * 5ae958d74180e2572d198bd7872c86f391de6da7
      * 5b08ac571ff8e94fe96511a532f0d20997de5f52
      * 3d04ff3a5d3ce3616837e1d15e03b6e1b360cf26
      * b2ef2c014b9c66995a3eb4f310ae7c5c510279bf
      * 63c4ed22b5048c8701d8806026c23cc95f0df756
      * ac2b484c02b01307ab6bbe5d45ddbf16d64edf8c
      * e35fcef8b739ed24e083ff8a3078ac14e101cf67
      * 6fb8cbcb58a29fff73eb2101b34caa19a7f88eba
      * 8a492a675e566dc1e666df0a86cbf541442cb179
      * 5dbc3b6cc0b759bf4b22d851ccb9cbf3e3cbc6ef
      * c86434ccb576a3ce35b5a74f72b9f03bd45b522a
      * d22e4cc9397ed41534c9422d0b0ffef8c77bfa53
      * 15bac72bac03faeb3b725b1d208c62160f0c3ad7
      * c08fb0d7bba4015078406b28d3906ccc5fda9d5a
      * 10b3bedcb03386cc280113f552479793e4bac35f
      * 754f7da38b0904b4b989d3500cc8dd5be625cf6a
      * 3cdaa6adb113a088fdfb87aa6d7747557eccc58d
      * 962dba7828cf251a9025ccb43bc6effa30379b72
      * 3162f12e58c3a848db883916843b332b9f8c9d39
      * 1c06ba3100847da6bd1f2e011dc24fa8debd9615
      * 84b9230c404aed4fd3a7bb3d045ca367043dde8c
      * 090555538d4347a52807ba9f08cf20ed13206afe
      * 817328eea788c746131cf151b64fd250200da333
      * c3758feebf7c8786231465da664743c6f0ec79cc
      * 1ac7a2c7b448c851eb8976fcc290a906a4075203
      * c21cc9bcb38a87ff638d1099ca871d94a2192b31
      * 6484ba5ef092b62b7d2112c0d976dbd6d1a40fde
      * b8b4863d78bf26b39918fc753b03ed98ef262903
      * b76b818e6fe2061e778b3a9bbe63c554c3f9b3c1
      * 8e9f92e9d5d7737afdacf79b76d98c4c42980508 -- `_dl_map_object` in
        `sysdeps/mach/hurd/dl-sysdep.c`
      * 0e516e0e14f2f9783a21cd1727bc53776341f857
      * a1fb5e3ebe9d38b5ae6c5bfbfaa04882d52355bc
      * cf7c9078a5acdbb435498ace92cd81009637a971
      * db753e2cfb2051ebf20dc089f87c5b1297cc2cff
      * 4a531bb0b3b582cb693de9f76d2d97d970f9a5d5 -- looks good.
      * 5bd6dc5c2c68fe98691db9b40f87d9b68ea9565b
      * 451f001b50870604e1f2daef12f04f9f460d3997 +
        a85b5cb4d4a5fc56e2b38638d270bf2daa67eb6c -- BZ10484.  `nptl/Versions
        [libc] (GLIBC_PRIVATE): Export __libc_alloca_cutoff`.  We don't even
        define it yet.  Also see
        [[service_solahart_jakarta_selatan__082122541663/glibc___libc_alloca_cutoff_should_be_lowered]].
      * 1086d70d916fd0eb969b3d89ff88abd35f6a5c34
      * cfa28e560ef69372b9e15e9a2d924a0fbcfc7bca
      * 8cf8ce1702c354a8266e3cfa6ab54c2467d1873f
      * 68dc949774cb651d53541df4abdc60327f7e096b
      * 70181fddf1467996bea393d13294ffe76b8a0853
      * a77e8cbc394ab098aa1fc3f0a6645a38348d21ca
      * 32465c3ea007065acd8ca8199f130cdf4068130d
      * 18ba70a559c52719fd94a713cc380514d9d19125
      * 620a05296fe3380b7441ba7720e8b25c48a8c28c
      * [low] e6c61494125126d2ba77e5d99f83887a2ed49783 -- `Fix memory leak in
        TLS of loaded objects.` Do we need to replicate `nptl/allocatestack.c`
        hunk?
      * 6e04cbbe79f5965809fdbf1f28d7ae8b4af74d31 +
        1bfbe0d335d3fc44a492648b974a0db19975f6d8 -- `Fix
        pathconf(_PC_BUF_SIZE).`
      * 28377d1bf58625172a1734b92e835591d4d23a18 -- `Optimize fdopendir a bit.`
      * 7fb90fb89bbdf273ab7ab96517fe1b156cd7aee1 +
        6fb2dde3f1aa3a1419cb6c2dfa53dd1d506722a4 -- `Fix Linux getcwd for long
        paths`
      * f574184a0e4b6ed69a5d9a3234543fba6d2a7367 -- `Fix sched_setscheduler
        call in spawn implementation`
      * 3b85df27870a47ed1db84e948e37a5a50a178a92 +
        f50ef8f1efdd1f2b040acbb8324604f168e8832a -- sysconf
      * 68a3f91fcad464c4737c1eaed4ae0bf539801fb2 -- `Fix reporting of invalid
        timeouts in emulated pselect`
      * ea389b12b3b65c4a7fa91fa76f8c99867eb37865 -- `strndup -> __strndup`;
        strndupa?
      * 7e4afad5bcf49e03c3b987399c6a8f66a9018660 -- `Nicer output for negative
        error numbers in strerror_r`.  Change needed for
        `sysdeps/mach/_strerror.c`?
      * 7ea72f99966a65a56aedba817ee2413ff9b1f23c +
        adcd5c15d2a37794d021104160b425ff61f88219 -- `Always fill output buffer
        in XPG strerror function`.  Change needed for
        `sysdeps/mach/xpg-strerror.c`?
      * a91710475294c66d0005bdaae0919d36ef8ce3d2 -- sotruss ([[debugging]],
        [[service_solahart_jakarta_selatan__082122541663/profiling]]).  Does it work?
      * b1ebd700c5295a449f8d114740f0d1fb6e6b2eb5 +
        80e2212d8e59933a1641f029ebd360526ff0e074 +
        4997db742946d08be4378cf91221f558f928bc73 -- `Don't document si_code
        used for raise()`.  Also for `bits/siginfo.h`?
      * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- pldd, Does it work?
        Probably not: needs `/proc/[PID]/auxv`, `/proc/[PID]/exe`,
        `/proc/[PID]/mem` ([[!tag open_issue_hurd]],
        [[hurd/translator/procfs]]).
      * 9113ea1f3f29b3aee710efc829e85a9772bcb836 -- `--experimental-malloc`.
        Watch what happens.
      * 4e34ac6a1e256f40ab0d8eeed37aa1ea83440e76 -- `-defsym=_begin=0`.  Watch
        what happens.  Native build: apparently OK.
      * f781ef4015504e8a1da649c266584976238aa079 (`--with-default-link`) +
        1b74661a6b93a892ecb1c717dedeedba5c2a976c +
        fd5e21c75d8e9221d766f4bc922a237265514ec2.  Watch what happens.  Native
        build: `use-default-link = no`.
      * de283087c74f720cf8a7171972e72b5fa2b45e79 (`Handle Lustre filesystem`),
        4e5f31c847982997c856f03bbc35134e9fd0f61f (`Handle ext4 in
        {,f}pathconf`).  What about stuff like that for us?
      * d30cf5bb00bfb286ff14d931fb69f5b53724bcdc (`Find readelf with
        AC_CHECK_TOOL`).  Aren't there more in other configure.in and Makefile
        files?
      * 7a03a9c8c4b37b88ac5e82b557d974f3161ddaf9 (`Add read barriers in
        cancellation initialization`).  Is this needed in other places, too?
      * [low] 5744c68d78f6ca6c6500e2c8d3d85b3a31f4ed2a (`Align x86 TCB to 64
        bytes`).  Probably we have hidden somewhere such a constant, too (in
        libpthread).
      * d96de9634a334af16c0ac711074c15ac1762b23c +
        ecb1482ffd85fd3279642b1dc045aa867ad4d415 (`Try shell in posix_spawn*
        only in compat mode`).  Change looks good, but what about
        `SPAWN_XFLAGS_TRY_SHELL` for us?
      * 3ce1f2959437e952b9db4eaeed2407424f11a4d1 (`Make several tool features
        mandatory and simplify the code.`).  Generally looks good.
          * `locale/global-locale.c`: Apparently, no one is using
            `_HURD_THREADVAR_LOCALE`.  But it is exported via
            `hurd/threadvar.h`.
          * `mach/devstream.c`: reversed.  Fixed in
            `t/repair-mach_devstream.c`.
          * `malloc/arena.c`: should be OK.
      * `Remove support for !USE___THREAD`.
        d063d164335938d557460bebaa7cfe388157b627 (generally looks good;
        `csu/errno-loc.c` (should be OK); `include/errno.h` (fixed)) +
        (de82006d43e198fd162807c9adc720c7ebd728a3 +
        037e9fe21c92216ef7032ea2796781ec27ca182a) +
        995a80dfbcb443ead5aa22682c884ec5c827a2ea (discussing) +
        bc7e1c3667b577ad418f7520df2a7dbccea04ee9 (should be ok).
      * [OK] 22a89187139a9083ca73989bfd11597e0f85cb61 (`malloc: Remove all
        kinds of unused configuration options and dead code.`).  `NO_STARTER`
        changes (should be OK).
      * [high] `pagesize`, 02d46fc4b969e25e4ba0c54aa95fa98d7279bd05 (`Simplify
        malloc initialization`); aebae0537dcb408100b88c6b7647a7e858c43237,
        [[!sourceware_PR 11929]].  Is this all kosher for us?  See
        [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]].
      * [OK] 83cd14204559abbb52635006832eaf4d2f42514a (`Remove --wth-tls
        option, TLS support is required`).
      * a7c8e6a1478de9f990b11e5e853318ccbe4330f2 (`Fix invalid conversion in
        __cmsg_nxthdr`).  Probably just a C++ thing and not relevant for us;
        see [[!message-id "87r52nk1kx.fsf@kepler.schwinge.homeip.net"]].
      * [low] `mmap`, 110946e473b38fc3896212e416d9d7064fecd5b7.  Kosher with
        respect to our [[glibc/mmap]] peculiarities?
      * [OK] `__attribute__ ((__leaf__))`, `BZ #13344`,
        aa78043a4aafe5db1a1a76d544a833b63b4c5f5c +
        49a43d80ec5c97cf6136b1ee2687414773b2d5aa +
        3871f58f065dac3917eb18220a479e9591769c8c +
        9beb2334930db81ceada5aa6051fe5ac0554db32 +
        0ffc4f3ebaace42cd545db55a2ac50b6e0cc7d89 +
        edc5984d4d18296d7aa3d8f4ed8f7336a743170e +
        57769839788e2c62b68d9dfbf4b35052321278ba.
        <http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html>.
      * [low] `conformtest`, 3134156779108fe8b46e0f4cd60d837572faaa93 +
        4efeffc1d583597e4f52985b9747269e47b754e2 +
        d94a4670800de6e8f088b8630ad5142866127980 -- should probably mirror
        `bits/siginfo.h` changes.
      * [low] stack guard, 6c6a98c983c44b440ae66d2aa8f32529a9dd7bfe,
        [[!message-id "4F3BE241.9090409@mentor.com"]] -- anything needed for
        us?
      * [low] `libc-lockP.h` 9463518d0d314d7bd0160315e0ef30e15be08985 --
        probably should do similar changes, also to the generic file.
      * [low] `bits/socket.h`/`bits/socket_type.h` [[!message-id
        "Pine.LNX.4.64.1203090206420.18868@digraph.polyomino.org.uk"]]
        02a6f887cb3e2c048937111eb4cf150d397609de -- probably should do the same
        for the generic version as used by GNU Hurd.
      * [low] CFI for `_start`, 6a1bd2a100c958d30bbfe8c9b8f9071d24b7c3f4,
        [[!message-id "20120316180551.GA6291@host2.jankratochvil.net"]] -- what
        about other architectures?
      * `linkobj/libc.so`, 510bbf14b4f25fec8ee3a2d24de3f24bdbf84333 -- need to
        adapt for (conditional?) Sun RPC reversion (if that was the original
        cause for the patch)?
      * [low] `Add __fsword_t and use it in bits/statfs.h`,
        3e5aef87d76cfa7354f2b0d82b96e59280720796, [[!message-id
        "20120517134700.GA19046@intel.com"]] -- only updates one copy of
        `bits/statfs.h`; update the others, too, for consistency.
      * [low] 789bd351b45f024b7f51e4886bf46b8e887ab6da: remove
        `libc_hidden_def` in `sysdeps/mach/hurd/accept4.c`?
      * 0948c3af9dfb3bc1312d6bed2f3a6bfd4e96eef4,
        b80af2f40631871cf53a5e39d08d5d5516473b96,
        04570aaa8ad88caad303f8afe469beb4cf851e17 `_dl_initial_dtv`: OK?
      * [very low] ea4d37b3169908615b7c17c9c506c6a6c16b3a26 `Implement
        POSIX-generic sleep via nanosleep rather than SIGARLM.`: any benefit
        using that one (with `sysdeps/mach/nanosleep.c`) instead of
        `sysdeps/mach/sleep.c`?
      * ea4d37b3169908615b7c17c9c506c6a6c16b3a26 -- IRC, freenode, #hurd,
        2012-11-20, pinotree: »tschwinge: i agree on your comments on
        ea4d37b3169908615b7c17c9c506c6a6c16b3a26, especially since mach's
        sleep.c is buggy (not considers interruption, extra time() (= RPC)
        call)«.
      * ba384f6ed9275f3966505f2375b56d169e3dc588,
        0409959c86f6840510851a851a1588677a2e537b,
        e57b0c6100e63bfd816ae59339452eafc81f1d3a `C++11 thread_local
        destructors support`.  Anything needed to be done in our [[service_solahart_jakarta_selatan__082122541663/libpthread]]
        and configured for us in [[service_solahart_jakarta_selatan__082122541663/Gcc]]?  Probably need to replicate the
        `nptl/pthread_create.c` change, and fix
        `stdlib/Makefile`:`$(objpfx)tst-tls-atexit`.

            +++ include/link.h
            @@ -302,6 +302,9 @@ struct link_map
            +    /* Number of thread_local objects constructed by this DSO.  */
            +    size_t l_tls_dtor_count;
            
            +++ include/stdlib.h
            @@ -100,6 +100,11 @@ extern int __cxa_atexit (void (*func) (void *), void *arg, void *d);
            +extern int __cxa_thread_atexit_impl (void (*func) (void *), void *arg,
            +                                    void *d);
            +extern void __call_tls_dtors (void);
            +libc_hidden_proto (__call_tls_dtors);
            
            +++ nptl/pthread_create.c
            @@ -311,6 +311,9 @@ start_thread (void *arg)
             [after the thread function returns]
            +  /* Call destructors for the thread_local TLS variables.  */
            +  __call_tls_dtors ();
            
            +++ stdlib/Makefile
            +$(objpfx)tst-tls-atexit = $(common-objpfx)nptl/libpthread.so \
            +                        $(common-objpfx)dlfcn/libdl.so
            
            +++ stdlib/cxa_thread_atexit_impl.c
            
            +++ stdlib/exit.c
             __run_exit_handlers (int status, struct exit_function_list **listp,
                                 bool run_list_atexit)
             {
            +  /* First, call the TLS destructors.  */
            +  __call_tls_dtors ();

            +gcc-4.7 tst-tls-atexit.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parenth
            +gcc-4.7 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build/stdlib/tst-tls-atexit   [...]/tschwinge/Roger_Whittaker.build/nptl/lib
            +gcc-4.7: error: [...]/tschwinge/Roger_Whittaker.build/nptl/libpthread.so: No such file or directory
            +make[2]: *** [[...]/tschwinge/Roger_Whittaker.build/stdlib/tst-tls-atexit] Error 1
            +gcc-4.7 tst-tls-atexit-lib.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-par
            +tst-tls-atexit-lib.c: In function 'do_foo':
            +tst-tls-atexit-lib.c:35:3: warning: implicit declaration of function '__cxa_thread_atexit_impl' [-Wimplicit-function-declaration]
      * a600e5cef53e10147932d910cdb2fdfc62afae4e `Consolidate Linux and POSIX
        libc_fatal code.` -- is `backtrace_and_maps` specific to Linux?

        IRC, freenode, #hurd, 2014-02-06:

            <braunr> why wouldn't glibc double free detection code also print
              the backtrace on hurd ?
            <youpi> I don't see any reason why
            <youpi> except missing telling glibc that it's essentially like on
              linux

      * 288f7d79fe2dcc8e62c539f57b25d7662a2cd5ff `Use __ehdr_start, if
        available, as fallback for AT_PHDR.` -- once we require Binutils 2.23,
        can we simplify [[glibc's process startup|glibc/process]]
        (initialization of `_dl_phdr` and `_dl_phnum`)?  As these are only used
        for `[!SHARED]`, can we completely remove them (that is, the `phdr` and
        `phdrsz` members) from `hurd_startup_data`, and simplify
        [[hurd/interface/exec_startup_get_info]], or do we still require these
        for the `[SHARED]` case?
      * fab7ce3f5b4060bf62659e8b58529de4156b5a2f `Link extra-libs consistently
        with libc and ld.so.`  Alright for us?  Probably have to adjust
        [libpthread]/Makefile.
      * b8c61b4b1d6afb69190169764c1b141f4659e48b `Remove trailing whitespace
        from mach/*.sub.`  Update `mach/Makefile`: generated
        `mach/errsystems.c` is no longer checked in as of
        66e3dda448406399136e6f144a1b46679d5b2613.  Rule had been disabled in
        421f82e5cc8f81ab003247d771bcecbad799be85, then re-enabled in
        8e3cc80f6d4f69ce003c82d3561ac324692792ad, but comment not removed.
      * [low] 61dd6208fb1e59a423b6dfa712a3c896c34b2590 `New API to set default
        thread attributes`.  Implement in libpthread ([[!taglink
        open_issue_libpthread]])?
      * [high] e4608715e6e1dd2adc91982fd151d5ba4f761d69 `CVE-2013-2207, BZ
        #15755: Disable pt_chown. -- [[!message-id
        "51E8D4C1.9000705@redhat.com"]]; do we need it (`--enable-pt_chown`)?
	cdfc721b8d2d5079325ea9f0beb5673d72b4cdd0.
      * 91ce40854d0b7f865cf5024ef95a8026b76096f3 `CVE-2013-4237, BZ #14699:
        Buffer overflow in readdir_r` -- [[!message-id
        "519220C7.6050705@redhat.com"]]; do we need corresponding changes to
        Hurd sysdep files?
      * 8cc3269f95fa7faa8f448d741f68cbc40efbf4ee `Flesh out 4.4 bits/socket.h
        with SOCK_CLOEXEC, SOCK_NONBLOCK.`,
        e041fb8b6557882b6710a655a97bbf3541b56b54 `Replace generic bits/socket.h
        with 4.4 file.` -- `sysdeps/mach/hurd/bits/socket.h` differs from the
        generic `bits/socket.h` now only in the values of
        [[`SOCK_CLOEXEC`|service_solahart_jakarta_selatan__082122541663/secure_file_descriptor_handling]] and
        `SOCK_NONBLOCK`.  If possible (no conflicts), would it make sense to
        transition to the latter file, continuing to accept the former values
        as deprecated for some time?
      * [high] 6a97b62a5b4f18aea849d6f4d8de58d1469d2521 `Fix unsafe compiler
        optimization` -- have to revert, see [[!sourceware_PR 15605]].  For
        analysis/fix also look at 384ca551743318bd9c9e24a496d6397f2e3f2a49.
      * 6c82a2f8d7c8e21e39237225c819f182ae438db3 `Coordinate IPv6 definitions
        for Linux and glibc` -- alright for us?
      * c61b4d41c9647a54a329aa021341c0eb032b793e `POINTER_CHK_GUARD` -- see
        [[t/tls|service_solahart_jakarta_selatan__082122541663/glibc/t/tls]].
      * 5f855e3598a576c35e54623a13b256f3e87fcd4d `Fix erroneous (and circular)
        implied pattern rule for linkobj/libc.so.` -- alright for us?
      * [high] 7b7bab1391a3b16fff7e325e2c8a36b68eacba90 [Hurd] `Add fork hooks
        for pthread_atfork` -- is that from a topic branch that can then be
        annihilated?  Verify emails.  Verify no further changes in topic
        branch.
      * [high] 43d5c02c72bdaf59a8e0d4b06f2ae87e42269cbd `Fix build on hurd` --
        is that from a topic branch that can then be annihilated?  Verify
        emails.  Verify no further changes in topic branch.
      * 69a17d9d245dc3551792e95e1823cc2d877592f3 `Patch [1/4] async-signal safe
        TLS.` -- do we also need an implementation of this?  (Not yet called
        from anywhere?)
      * *baseline*


## Update

`baseline`, `t/regenerate_configure` (could now be removed),
`t/master_backports`, `t/eglibc_backports`, `t/host-independency`,
`tschwinge/Roger_Whittaker`


# Build

Here's a log of a glibc build run; this is from our [[Git repository's
f57644d0bdfc1ebe2201a677a33af27e09a5bab6 (2013-12-20;
64a17f1adde4715bb6607f64decd73b2df9e6852 (2013-12-19))
plus 6a97b62a5b4f18aea849d6f4d8de58d1469d2521 reverted,
`id:"87zjnvn688.fsf@kepler.schwinge.homeip.net"`,
`id:"87ioujn0eq.fsf@kepler.schwinge.homeip.net"`,
1226676cd6f6f4451e6e6b75b8fbd9a35c949e8e reverted,
56798c444bc584c118b69a3506c4050b34edc35f reverted,
`id:"878uvfmwvs.fsf@kepler.schwinge.homeip.net"`
sources|source_repositories/glibc]], run on coulomb.SCHWINGE.

    $ export LC_ALL=C
    $ ../Roger_Whittaker/configure --prefix=/usr --disable-profile --disable-multi-arch --build=i486-gnu --host=i486-gnu CC=gcc-4.7 CXX=g++-4.7 2>&1 | tee log_build
    [...]
    $ make install_root=/INVALID 2>&1 | tee log_build_
    [...]

This takes up around 600 MiB, and needs roughly X min on kepler.SCHWINGE and
105 min on coulomb.SCHWINGE.

<!--

    $ (make install_root=/INVALID && touch .go-install) 2>&1 | tee log_build_ && test -f .go-install && (make install_root="$PWD".install install && touch .go-test) 2>&1 | tee log_install && test -f .go-test && ln -s /usr/lib/i386-*gnu/libstdc++.so.6 /lib/i386-*gnu/libgcc_s.so.1 mach/libmachuser.so.1 hurd/libhurduser.so.0.3 ./ && make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test

-->


## Analysis

    $ toolchain/logs/process glibc build fetch coulomb.SCHWINGE

TODO.

  * baseline
    fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b
    (or probably Samuel's mmap backport) introduces:

        ../sysdeps/mach/hurd/mmap.c: In function '__mmap':
        ../sysdeps/mach/hurd/mmap.c:54:15: warning: comparison between pointer and integer [enabled by default]
        ../sysdeps/mach/hurd/mmap.c:66:21: warning: comparison between pointer and integer [enabled by default]
        ../sysdeps/mach/hurd/mmap.c:143:13: warning: comparison between pointer and integer [enabled by default]
        ../sysdeps/mach/hurd/mmap.c:165:24: warning: comparison between pointer and integer [enabled by default]

  * baseline
    fd5bdc0924e0cfd1688b632068c1b26f3b0c88da..2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b
    introduces:

        nscd_gethst_r.c: In function '__nscd_get_nl_timestamp':
        nscd_gethst_r.c:112:4: warning: implicit declaration of function 'time' [-Wimplicit-function-declaration]

    This was already present before:

        nscd_gethst_r.c: In function 'nscd_gethst_r':
        nscd_gethst_r.c:426:5: warning: implicit declaration of function '__close' [-Wimplicit-function-declaration]

  * baseline
    2ba92745c36eb3c3f3af0ce1b0aebd255c63a13b..7a270350a9bc3110cd5ba12bbd8c5c8c365e0032
    introduces:

        tst-relsort1.c:6:1: warning: function declaration isn't a prototype [-Wstrict-prototypes]

  * baseline
    fc56c5bbc1a0d56b9b49171dd377c73c268ebcfd..cbc818d0ee66065f3942beffdca82986615aa19a
    introduces

        +gcc-4.6 tst-printf-round.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes         -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.
        +tst-printf-round.c: In function 'do_test':
        +tst-printf-round.c:203:11: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
        +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
        +tst-printf-round.c:208:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
        +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
        +tst-printf-round.c:216:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
        +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'
        +tst-printf-round.c:224:8: warning: passing argument 3 of 'test_hex_in_one_mode' discards 'const' qualifier from pointer target type [enabled by default]
        +tst-printf-round.c:139:1: note: expected 'const char **' but argument is of type 'const char * const*'

         gcc-4.6 test-wcschr.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes         -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486
        +In file included from test-wcschr.c:2:0:
        +../string/test-strchr.c: In function 'check1':
        +../string/test-strchr.c:249:3: warning: passing argument 1 of 'stupid_STRCHR' from incompatible pointer type [enabled by default]
        +../string/test-strchr.c:77:1: note: expected 'const wchar_t *' but argument is of type 'char *'
        +../string/test-strchr.c:249:22: warning: initialization from incompatible pointer type [enabled by default]
        +../string/test-strchr.c:252:5: warning: passing argument 2 of 'check_result' from incompatible pointer type [enabled by default]
        +../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *'
        +../string/test-strchr.c:252:5: warning: passing argument 4 of 'check_result' from incompatible pointer type [enabled by default]
        +../string/test-strchr.c:92:1: note: expected 'const wchar_t *' but argument is of type 'char *'


# Install

TODO.

    $ make install_root="$PWD".install install 2>&1 | tee log_install
    [...]

This takes up around 100 MiB, and needs roughly X min on kepler.SCHWINGE and 16
min on coulomb.SCHWINGE.


## Analysis

    $ toolchain/logs/process glibc install fetch coulomb.SCHWINGE

TODO.


# Testsuite

    $ make -k install_root=/INVALID check fast-check=yes 2>&1 | tee log_test
    [...]

This needs roughly X min on kepler.SCHWINGE and 130 min on coulomb.SCHWINGE.

Specifying `fast-check=yes` disables the `conformtest` which takes 1.75 h (out
of 2.75 h total) on coulomb.SCHWINGE, doesn't pass anyway, and clearly isn't
our most critical issue to solve.
`elf/tst-xmmymm.out` is another candidate to disable: needs 90 min to run.


## Analysis

    $ toolchain/logs/process glibc test fetch coulomb.SCHWINGE

Failures, mostly in order of appearance:

  * `check-abi`, `check-abi-libmachuser`, `check-abi-libhurduser`,
    `check-abi-libBrokenLocale`, `check-abi-libm`, `check-abi-libdl`,
    `check-abi-libcrypt`, `check-abi-libresolv`, `check-abi-librt`,
    `check-abi-libnsl`, `check-abi-libutil`, `check-abi-libc`, `check-abi-ld`,
    `c++-types.data`

    Reference files are missing.

  * `math/test-float.out`, `math/test-double.out`

    A handful of ULP failures.

  * `math/test-ldouble`, `math/test-ildoubl`, `math/test-ifloat`,
    `math/test-idouble`

    SIGSEGV.  Or SIGILL.

  * `stdlib/tst-secure-getenv.out`

        open (/proc/self/exe): No such file or directory

    Needs [[`/proc/self/exe`|hurd/translator/procfs/jkoenig/discussion]].

  * `stdlib/tst-strtod-round.out`

        strtold (-0x0.7p-16445) returned -0x0.0000000000008p-16385 not -0x0.000000000000001p-16385 (FE_DOWNWARD)
        strtold (-0x0.7p-16494) returned -0x0.0000000000008p-16385 not -0x0.000000000000001p-16385 (FE_DOWNWARD)

  * `stdio-common/bug22.out`

        Timed out: killed the child process

    Known problem.

  * `libio/tst-atime.out`, `dirent/tst-fdopendir.out`

    [[!message-id "201305102256.56636.toscano.pino@tiscali.it"]].

    `libio/tst-atime.out`:

        atime has not changed

    Due to `ext2fs --no-atime`.

      * IRC, OFTC, #debian-hurd, 2013-05-08

            <youpi> bah, tst-atime failure :)
            <pinotree> do you have its output?
            <youpi> well it's very simple
            <youpi> I have the noatime option on / :)
            <pinotree> oh
            <youpi> fortunately fsysopts works :)
            <pinotree> the test checks whether ST_NOATIME is in the mount
              options, maybe it would be a good idea to provide it
            <youpi> yes
            <pinotree> unfortunately it isn't in posix, so i'm not sure whether
              adding it to the general bits/statvfs.h would be welcome
            <pinotree> or whether we should fork it, like it is done for linux 
            <pinotree> oh no, we fork it already
            <pinotree> \o/

    `dirent/tst-fdopendir.out`:

        directory atime changed

    Due to `ext2fs --atime` (default).

  * `libio/tst-fopenloc.check`, `posix/bug-regex31-mem`,
    `posix/tst-fnmatch-mem`, `misc/tst-error1-mem`

        Memory not freed:
        -----------------
           Address     Size     Caller
        0x0807e268   0x8000  at 0x10c71c4

    Caused by different memory allocation way in libio, see
    [[!message-id "87mxd9hl2n.fsf@kepler.schwinge.homeip.net"]]

  * `dlfcn/bug-atexit3.out`

    Originally:

        dlopen failed: libstdc++.so.6: cannot open shared object file: No such file or directory

    See [[!message-id "20090420002344.11798.qmail@s461.sureserver.com"]].
    Hacked around with `ln -s /usr/lib/i386-*gnu/libstdc++.so.6
    /lib/i386-*gnu/libpthread-stubs.so.0 /lib/i386-*gnu/libgcc_s.so.1 ./`.
    This is a bug in the glibc test harness.  Should probably use some
    `configure` magic akin to the `fixincludes` stuff (`gcc-4.4
    -print-file-name=libstdc++.so.6`, etc.).

    Even if that that is being worked around, the tests nowadays
    ([[service_solahart_jakarta_selatan__082122541663/packaging_libpthread]]) fail with:

        dlopen failed: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libstdc++.so.6)

  * `dlfcn/tststatic.out`, `dlfcn/tststatic2.out`, `dlfcn/tststatic3.out`,
    `dlfcn/tststatic4.out`, `dlfcn/tststatic5.out`

    SIGSEGV.

    `LD_LIBRARY_PATH` doesn't contain the `mach` and `hurd` directories; yet
    the test shouldn't just SIGSEGV.

  * `dirent/opendir-tst1.out`, `dirent/tst-fdopendir2.out`

    `dirent/opendir-tst1.out`:

        `opendir' succeeded on a FIFO???

    `dirent/tst-fdopendir2.out`:

        fdopendir with normal file descriptor did not fail

    `opendir` and `fdopendir` do not return `ENOTDIR` if `fd` is not a
    directory.

  * `posix/tst-waitid.out`

    Intermittent.

        SIGCHLD for stopped status 0
        SIGCHLD for stopped pid -1
        SIGCHLD for killed code 1
        SIGCHLD for killed status 0
        SIGCHLD for killed pid -1

  * `posix/bug-glob2.out`

    Intermittent.

        Timed out: killed the child process

  * `posix/annexc.out`

    Failure ignored by the glibc testsuite.

  * `posix/tst-getconf.out`

    Ends with:

        getconf POSIX_ALLOC_SIZE_MIN /: [...]/posix/getconf: pathconf: /: Invalid argument

    It fails because of unimplemented pathconf cases: `_PC_ALLOC_SIZE_MIN`,
    `_PC_REC_INCR_XFER_SIZE`, `_PC_REC_MAX_XFER_SIZE`, `_PC_REC_MIN_XFER_SIZE`,
    `_PC_REC_XFER_ALIGN`, `_PC_SYMLINK_MAX`, `_PC_2_SYMLINKS`.

    `_CS_GNU_LIBPTHREAD_VERSION` is provided by libpthread when compiled as
    add-on.

  * `posix/tst-vfork3-mem`

        + 0x0804cee0 Alloc 10 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
        + 0x0804cf90 Alloc 11 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
        + 0x0804cfa8 Alloc 12 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x00000008 Alloc 17 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x0804cee0 Alloc 18 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
        + 0x0804cf90 Alloc 19 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
        + 0x0804cfa8 Alloc 20 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x00000008 Alloc 25 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x0804cee0 Alloc 26 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
        + 0x0804cf90 Alloc 27 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
        + 0x0804cfa8 Alloc 28 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x00000008 Alloc 33 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x0804cee0 Alloc 34 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
        + 0x0804cf90 Alloc 35 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
        + 0x0804cfa8 Alloc 36 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x00000008 Alloc 41 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x0804cee0 Alloc 42 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
        + 0x0804cf90 Alloc 43 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
        + 0x0804cfa8 Alloc 44 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x00000008 Alloc 49 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x0804cee0 Alloc 50 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
        + 0x0804cf90 Alloc 51 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
        + 0x0804cfa8 Alloc 52 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x00000008 Alloc 57 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x0804cee0 Alloc 58 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
        + 0x0804cf90 Alloc 59 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
        + 0x0804cfa8 Alloc 60 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x00000008 Alloc 65 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x0804cee0 Alloc 66 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
        + 0x0804cf90 Alloc 67 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
        + 0x0804cfa8 Alloc 68 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x00000008 Alloc 73 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x0804cee0 Alloc 74 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
        + 0x0804cf90 Alloc 75 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
        + 0x0804cfa8 Alloc 76 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x00000008 Alloc 81 duplicate: 0x10df0c8 $BUILDDIR/libc.so.0.3:(argz_create+0x68)[0x10df0c8]
        + 0x0804cee0 Alloc 82 duplicate: 0x1095389 $BUILDDIR/libc.so.0.3:[0x1095389]
        + 0x0804cf90 Alloc 83 duplicate: 0x1156963 $BUILDDIR/libc.so.0.3:(tsearch+0xe3)[0x1156963]
        - 0x0804c8d8 Free 84 was never alloc'd 0x10955fc
        - 0x0804c960 Free 87 was never alloc'd 0x115672f
        - 0x0804c9b8 Free 88 was never alloc'd 0x1156737
        
        Memory not freed:
        -----------------
           Address     Size     Caller
        0x0804cfa8     0x73  at 0x10df0c8
        0x00000008        0  at 0x10df0c8

    Perhps because we implement `vfork` in terms of `fork` (`posix/vfork.c`)?

  * `posix/tst-pathconf.out`

        pathconf on directory failed: (os/kern) successful

  * `io/test-lfs.out`

        /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build/io/test-lfs: cannot write test string to large file: Invalid argument

  * `io/tst-futimesat.out`

        file created
        futimesat failed

    `futimesat` is a stub.

  * `misc/tst-pselect.o`

        tst-pselect.c: In function 'do_test':
        tst-pselect.c:33:17: error: 'SA_NOCLDWAIT' undeclared (first use in this function)

  * `gmon/tst-sprofil.out`

        Floating point exception

  * `nss//libnss_test1.so`

        [...]/nss/nss_test1.os: In function `_nss_test1_getpwent_r':
        [...]/nss/nss_test1.c:60: undefined reference to `pthread_mutex_lock'
        [...]/nss/nss_test1.c:85: undefined reference to `pthread_mutex_unlock'

  * `rt/tst-shm.out`

        read file outside of SHMDIR directory: (os/kern) successful

  * `rt/tst-timer.out`

    No message.

  * `rt/tst-timer2.o`

        tst-timer2.c: In function 'do_test':
        tst-timer2.c:33:23: error: 'SIGRTMIN' undeclared (first use in this function)

  * `rt/tst-aio2`, `rt/tst-aio3`, `rt/tst-aio9`, `rt/tst-aio10`,
    `rt/tst-mqueue3`, `rt/tst-mqueue5.o`, `rt/tst-mqueue6`, `rt/tst-mqueue8`,
    `rt/tst-timer3`, `rt/tst-timer4.o`, `rt/tst-timer5.o`,
    `rt/tst-cputimer1.o`, `rt/tst-cputimer2.o`, `rt/tst-cputimer3.o`,
    `elf/tst-thrlock`

        [...]/rt/tst-aio2.o: In function `do_test':
        [...]/rt/tst-aio2.c:62: undefined reference to `pthread_barrier_init'
        [...]/rt/tst-aio2.c:94: undefined reference to `pthread_barrier_wait'
        [...]/rt/tst-aio2.o: In function `thrfct':
        [...]/rt/tst-aio2.c:35: undefined reference to `pthread_barrier_wait'

        tst-mqueue5.c: In function 'rtmin_handler':
        tst-mqueue5.c:50:14: error: 'SIGRTMIN' undeclared (first use in this function)

        [...]/rt/tst-mqueue6.o: In function `do_test':
        [...]/rt/tst-mqueue6.c:127: undefined reference to `pthread_attr_init'
        [...]/rt/tst-mqueue6.c:149: undefined reference to `pthread_attr_setguardsize'
        [...]/rt/tst-mqueue6.c:211: undefined reference to `pthread_attr_setguardsize'
        [...]/rt/tst-mqueue6.c:262: undefined reference to `pthread_attr_destroy'
        [...]/rt/tst-mqueue6.c:128: undefined reference to `pthread_attr_setguardsize'
        [...]/rt/tst-mqueue6.o: In function `fct':
        [...]/rt/tst-mqueue6.c:79: undefined reference to `pthread_self'
        [...]/rt/tst-mqueue6.c:79: undefined reference to `pthread_getattr_np'
        [...]/rt/tst-mqueue6.c:88: undefined reference to `pthread_attr_getguardsize'
        [...]/rt/tst-mqueue6.c:95: undefined reference to `pthread_attr_destroy'
        [...]/rt/tst-mqueue6.c:95: undefined reference to `pthread_attr_destroy'

        [...]/elf/tst-thrlock.o: In function `do_test':
        [...]/elf/tst-thrlock.c:38: undefined reference to `pthread_create'
        [...]/elf/tst-thrlock.c:48: undefined reference to `pthread_join'

  * `rt/tst-aio8.out`

        r = -1, e = 1073741902 (Function not implemented)

    Should work with [[!message-id
    "201209302353.51055.toscano.pino@tiscali.it"]] in libpthread.

  * `debug/tst-chk1.out`

    Intermittent.  Timeout.  Unknown.

  * `debug/tst-chk2.out`, `debug/tst-chk3.out`, `debug/tst-lfschk2.out`,
    `debug/tst-lfschk3.out`

    Unknown.

  * `debug/tst-chk4.out`, `debug/tst-chk5.out`, `debug/tst-chk6.out`,
    `debug/tst-lfschk4.out`, `debug/tst-lfschk5.out`, `debug/tst-lfschk6.out`

        [...]/debug/tst-chk4: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libstdc++.so.6)
        [...]/debug/tst-chk4: [...]/libc.so.0.3: version `GLIBC_2.13_DEBIAN_31' not found (required by [...]/libgcc_s.so.1)

  * `debug/tst-longjmp_chk2.out`

    SIGSEGV.

        not on alternate stack
         in signal handler
         on alternate stack
         out of signal handler
         on alternate stack

    It says *alternate stack*.

  * `inet/tst-ether_line.o`

        tst-ether_line.c: In function 'do_test':
        tst-ether_line.c:19:19: error: 'ETH_ALEN' undeclared (first use in this function)

    Will either need a `hurd/netinet/if_ether.h` that includes
    `<net/if_ether.h>`, or can do that in the generic `netinet/if_ether.h`?
    See also [[!sourceware_PR 11142]].

  * `login/tst-grantpt.out`

        posix_openpt(O_RDWR) failed
        errno 1073741902 (Function not implemented)

    `posix_openpt` is a stub.

        grantpt(): expected: return = -1, errno = 1073741846
                   got: return = -1, errno = -303

    `grantpt` (actually `ptsname_r`), does not fail with `ENOTTY` when the `fd`
    does not refer to a PTY master.

  * `elf/tst-auxv.out`

    SIGSEGV.

  * `elf/tst-stackguard1-static.out`, `elf/tst-stackguard1.out`

        differences 0 defaults 0
        stack guard canaries are not randomized enough
        nor equal to the default canary value

    Sometimes times out.

  * `elf/tst-ptrguard1-static.o`, `elf/tst-ptrguard1.o`

        In file included from tst-ptrguard1-static.c:1:0:
        tst-ptrguard1.c: In function 'con':
        tst-ptrguard1.c:42:24: error: 'tcbhead_t' has no member named 'pointer_guard'
        tst-ptrguard1.c: In function 'do_test':
        tst-ptrguard1.c:65:29: error: 'tcbhead_t' has no member named 'pointer_guard'
        tst-ptrguard1.c:104:30: error: 'tcbhead_t' has no member named 'pointer_guard'

    See [[t/tls|service_solahart_jakarta_selatan__082122541663/glibc/t/tls]].

  * `elf/tst-tls9-static.out`

    SIGSEGV.

  * `elf/tst-dlmopen1.out`

    SIGSEGV.

  * `elf/tst-audit1.out`, `elf/tst-audit2.out`, `elf/tst-audit8.out`

    SIGKILL.

  * `elf/tst-null-argv.out`

        Inconsistency detected by ld.so: ../sysdeps/mach/hurd/dl-sysdep.c: 338: open_file: Assertion `!(flags & ~(0x0001 | 0x00400000))' failed!

  * `elf/check-textrel.out`

        $BUILDDIR/libc.so.dyn: *** text relocations used

  * `elf/check-execstack.out`

        $BUILDDIR/libc.so.phdr: *** executable stack signaled

  * `elf/check-localplt.out`

    Around 500 or so `Extra PLT reference`.

  * `check-local-headers.out`

    A lot.  Including `/usr/include/device/*.h`, `/usr/include/mach/*.h`,
    `/usr/include/hurd/*.h`.

  * `debug/tst-longjmp_chk2.out`, `debug/tst-longjmp_chk3.out`,
    `debug/tst-longjmp_chk4.out`, `debug/tst-longjmp_chk5.out`,
    `debug/tst-backtrace2.out`, `debug/tst-backtrace3.out`,
    `debug/tst-backtrace4.out`, `debug/tst-backtrace5.out`
    `debug/tst-backtrace6.out`

    All say: `Obtained backtrace with 0 functions`.

Earlier failures; no longer seen:

  * `test-assert-perr.out`

    Fails intermittently.  Unknown.

  * `test-multiarch.out`

    Needs [[`/proc/cpuinfo`|hurd/translator/procfs/jkoenig/discussion]]
    providing the `flags` line.

  * `elf/tst-array*`

    No longer fail with GCC 4.7.
    [[!message-id "50950082.1070906@df1tl.local.here"]].

  * `io/ftwtest`, `posix/globtest`, `iconvdata/iconv-test`, `intl/tst-gettext`,
    `malloc/tst-mtrace`, `elf/tst-pathopt`, `iconvdata/tst-tables`,
    `grp/tst_fgetgrent`,
    `posix/wordexp-tst`, `localedata/bug-setlocale1.out`, `posix/tst-getconf`

        /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/io/ftwtest: error while loading shared libraries: libmachuser.so.1: cannot open shared object file: No such file or directory

    Looking into `localedata/bug-setlocale1.c`, it is clear what it going on:
    only the root of the build directory is added for `--library-path`, but
    none of the other directories that are additionally used.  This is a bug in
    the glibc test harness.  Hacked around by `ln -s mach/libmachuser.so.1
    hurd/libhurduser.so.0.3 ./`.  Hopefully the other instances are similar.

  * `assert/test-assert.out`

    Fails sometimes...

  * `math/test-fenv.out`

    Used to fail (is listed in Debian eglibc-2.13-21's
    `expected-results-i486-gnu-libc`), but something between
    22bcba37dd3b782b1a1ec7bf51da468e48f4d2eb and
    005b7594ffe209639dd1ef2b9ed9a4c22307dec1 causes it to passe -- very likely
    Jérémie's signaling work.

  * `elf/tst-unused-dep.out` (1f393a11f65dcaa1952bdcaf0317a65a5f8aff9d,
    [[!sourceware_PR 13706]], [[!message-id "4F4210C1.1090704@redhat.com"]])

        Unused direct dependencies:
                /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.6-486/dlfcn/libdl.so.2

    As of 8958805c11c741d9211e20612c86271d906c9a0b, this test now passes --
    correct?

  * `stdlib/bug-getcontext.out`

        getcontext failed, errno: 1073741902.

    Fixed, implemented in `t/context_functions`.

  * `resource/bug-ulimit1.out`

        Result of ulimit (UL_SETFSIZE, 10000): 0
        Result of ulimit(UL_GETFSIZE): 10000

    Buggy `sysdeps/unix/bsd/ulimit.c` return values.

    Fixed, [[!message-id "201211182342.51619.toscano.pino@tiscali.it"]].

Compared to Debian:

    $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/convertlog.sh log_test  > log_test.filtered
    $ bash ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/compare.sh ~/tmp/glibc/debian/eglibc-2.13/debian/testsuite-checking/expected-results-i486-gnu-libc log_test.filtered