summaryrefslogtreecommitdiff
path: root/open_issues/glibc.mdwn
blob: 734806a15b42d995bd167ec881b1f709bc4c138e (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
[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012 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]]


# [[Sources|source_repositories/glibc]]


# [[Debian]] Cheat Sheet


# Configuration

<!--

git checkout reviewed
git log --reverse --pretty=fuller --stat=$COLUMNS,$COLUMNS -w -p -C --cc ..sourceware/master
-i
/^commit |^Merge:|^---$|hurd|linux|gs:|__ASSUME

-->

Last reviewed up to the [[Git mirror's d3bd58cf0a027016544949ffd27300ac5fb01bb8
(2012-11-03) sources|source_repositories/glibc]].

  * `t/hurdsig-fixes`

        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

  * `t/host-independency`

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

  * `t/sysvshm`

        ../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]

  * [[`t/tls`|t/tls]]

  * [[`t/tls-threadvar`|t/tls-threadvar]]

  * t/verify.h

    People didn't like this too much.

    Other examples:

      * 11988f8f9656042c3dfd9002ac85dff33173b9bd -- `static_assert`

  * [[toolchain/cross-gnu]], without `--disable-multi-arch`

        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.

  * `--disable-multi-arch`

    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.

  * --build=X

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

  * Check what all these are:

        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

  * `sysdeps/i386/stackguard-macros.h`

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

  * Verify 77c84aeb81808c3109665949448dba59965c391e against
    `~/shared/glibc/make_TAGS.patch`.

  * `HP_SMALL_TIMING_AVAIL` not defined anywhere.

  * Unify `CPUCLOCK_WHICH` stuff in `clock_*` files.

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

        $ 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

  * `CPUCLOCK_WHICH`, `t/cpuclock`

        /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

  * Missing interfaces, amongst many more.

    Many more are missing, some of which have been announced in `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 list.

    `AT_EMPTY_PATH`, `CLOCK_BOOTTIME`, `CLOCK_BOOTTIME_ALARM`,
    `CLOCK_REALTIME_ALARM`, `O_PATH`,
    `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27,
    b1b2aaf8eb9eed301ea8f65b96844568ca017f8b),
    `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`)
    `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`,
    `open_by_handle_at`, `process_vm_readv`, `process_vm_writev`, `sendmmsg`,
    `setns`, `sync_file_range`

      * `chflags`

        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

      * `getcontext`/`setcontext`

        Needed for [[gccgo]].

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

            <gnu_srs> How much work/knowledge is needed to implement
              getcontext/setcontext?
            <gnu_srs> Any already implemented alternatives available?
            <youpi> x86 registers knowledge, as well as unix signal masks
            <youpi> there's the linux implementation that can be taken as an
              exxample, but the signal part has to be rewritten
            <gnu_srs> Well, it's a pity they are not implemented. That's the
              remaining hurdle to get gccgo working :-( 
            <youpi> uh :/
            <gnu_srs> Everything builds, but the testsuite fails due to these
              missing functions.
            <gnu_srs> Regarding getcontext/setcontext they seem to be written
              in assembly for linux but the code is not very long. 
            <gnu_srs> How much effort would it be to write something similar
              for Hurd? Anybody fluent in asm?
            <gnu_srs> And registers and signals.
            <tschwinge> gnu_srs: Signals is the key thing -- everything else we
              can probably just copy.  I have never/not yet looked at it,
              though.
            <gnu_srs> For kfreebsd it is written in C: kern_context.c, 3/4 in
              one file: getcontext, setcontext,  swapcontext, not makecontext.
            <gnu_srs> Dunno how much assembly calls used though.
            <gnu_srs> Hi, any preferences about implementing get/setcontext in
              C or Asm?
            <tschwinge> gnu_srs: I think these will have to be implemented in
              assembly.  Based on the Linux x86 variants.

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

            <tschwinge> youpi: Your understanding of that is better than mine
              -- the *context stuff can't be very useful at the moment, because
              when the user changes uc_stack.ss_sp (which the glibc tests are
              doing), we're losing access to the _hurd_threadvars.  Correct?
            <tschwinge> At least the getcontext test works, the other get a
              SIGILL.
            <tschwinge> others
            <tschwinge> _hurd_threadvars issue is just guessing.
            <youpi> tschwinge: yes, threadvars are on the stack
            <youpi> threadvars is not much code, it should just work, but care
              has to be taken on the libpthread/libthread side, which does some
              initialization
            <tschwinge> OK, that at least matches my understanding.

      * [[`mremap`|mremap]]

      * `syncfs`

        We should be easily able to implement that one.

      * `futimesat`, `readlinkat`

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

      * `bits/stat.h [__USE_ATFILE]`: `UTIME_NOW`, `UTIME_OMIT`

      * `io/fcntl.h [__USE_ATFILE]`

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

      * `MAP_POPULATE` (`mmap`, `sys/mman.h`) -- *Populate (prefault)
        pagetables.*

        Some Linux kernel version, `mm/mmap.c`:

                if (vm_flags & VM_LOCKED) {
                        if (!mlock_vma_pages_range(vma, addr, addr + len))
                                mm->locked_vm += (len >> PAGE_SHIFT);
                } else if ((flags & MAP_POPULATE) && !(flags & MAP_NONBLOCK))
                        make_pages_present(addr, addr + len);
                return addr;

        Is only advisory, so can worked around with `#define MAP_POPULATE 0`,
        8069478040336a7de3461be275432493cc7e4c91.

      * `t/opendirat`: `opendirat` (`scandirat`, `scandirat64`)

        Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 +
        14d96785125abee5e9a49a1c3037f35a581750bd.

      * `madvise`, `MADV_DONTNEED`, `MADV_DONTDUMP`, `MADV_DODUMP`

        [[glibc_madvise_vs_static_linking]].

      * `msync`

        Then define `_POSIX_MAPPED_FILES`, `_POSIX_SYNCHRONIZED_IO`.

      * `sys/epoll.h`

        Used by [[wayland]], for example.

      * `sys/eventfd.h`

      * `sys/inotify.h`

      * `sys/signalfd.h`

      * `sys/timerfd.h`

      * `timespec_get` (74033a2507841cf077e31221de2481ff30b43d51)

      * `waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`)

        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

      * `getconf` things

        IRC, freenode, #hurd, 2012-10-03

            <pinotree> getconf -a | grep CACHE
            <Tekk_> pinotree: I hate spoiling data, but 0 :P
            <pinotree> had that feeling, but wanted to be sure -- thanks!
            <Tekk_> http://dpaste.com/809519/
            <Tekk_> except for uhh
            <Tekk_> L4 linesize
            <Tekk_> that didn't have any number associated
            <pinotree> weird
            <Tekk_> I actually didn't even know that there was L4 cache
            <pinotree> what do you get if you run `getconf
              LEVEL4_CACHE_LINESIZE`?
            <Tekk_> pinotree: undefined
            <pinotree> expected, given the output above

    For specific packages:

      * [[octave]]

  * Create `t/cleanup_kernel-features.h`.

  * Add tests from Linux kernel commit messages for `t/dup3` et al.

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

  * `/usr/include/pthread.h` overwrite issue

    `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.

  * `sysdeps/unix/sysv/linux/syslog.c`

  * `fsync` on a pipe

    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"]].

  * `t/no-hp-timing`

    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>?

  * `flockfile`/`ftrylockfile`/`funlockfile`

    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"]].

  * `t/pagesize`

    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

  * `LD_DEBUG`

    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.

  * Verify baseline changes, if we need any follow-up changes:

      * 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
        [[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.  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, `BZ
        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`?
      * *baseline*
      * 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)«.


## 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
28b74f8dbc3eb639d35fc0f93021ac5eb1fde9a4 (2012-11-03;
fbeafedeea37e0af1984a6511018d159f5ceed6a (2012-11-03))
sources|source_repositories/glibc]], run on coulomb.SCHWINGE.

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

This takes up around 500 MiB, and needs roughly X min on kepler.SCHWINGE and
100 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/libpthread-stubs.so.0 /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

Mask out gcc-4.X (with possibly a backslash before the dot), GCC 4.5's column
output for (warning, error) messages, GCC 4.6's `[-Wsomething]` or `[enabled by
default]` identifiers which warning flag triggered.

    $ for f in log_*; do sed -e 's%gcc-4\\\?.[456]%[GCC]%g' -e 's%g++-4\\\?.[456]%[G++]%g' -e 's%\(:[0-9]\+:\)[0-9]\+:%\1%' -e 's% \[\(-W[a-z-]\+\|enabled by default\)\]$%%' < "$f" > "$f".nv; done

    $ find ./ -name \*.o -o -name \*.os -o -name \*.oS | while read f; do ~/tmp/gcc/git/contrib/compare-debug --preserve ../Roger_Whittaker.build-gcc-4.4-486.O/"$f" "$f"; done 2>&1 | less 
    $ while read f; do (readelf -a "$f" && objdump -xDrtw "$f") > N && (cd ../Roger_Whittaker.build-gcc-4.4-486.O/ && readelf -a "$f" && objdump -xDrtw "$f") > O && diff -u O N | less; done
    $ find ./ -name \*.o -o -name \*.os -o -name \*.oS | while read f; do readelf -h "$f" | grep OS/ABI | (read a b && [ x"$b" != x'UNIX - System V' ] && echo "### $f: $b"); done

-->


## Analysis

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

TODO.

  * With GCC 4.5, there's a ton of these warnings:

        hurd/hurd.h: In function '__hurd_fail':
        hurd/hurd.h:73: warning: case value '0' not in enumerated type 'error_t'

    ... as well as a few individual instances:

        hurdselect.c: In function '_hurd_select':
        hurdselect.c:265: warning: case value '0' not in enumerated type 'error_t'
        get-host.c: In function '_hurd_get_host_config':
        get-host.c:38: warning: case value '0' not in enumerated type 'error_t'
        hurdmsg.c: In function '_S_msg_get_init_ints':
        hurdmsg.c:186: warning: case value '0' not in enumerated type 'error_t'
        hurdmsg.c: In function '_S_msg_set_init_ints':
        hurdmsg.c:273: warning: case value '0' not in enumerated type 'error_t'
        intr-msg.c: In function '_hurd_intr_rpc_mach_msg':
        intr-msg.c:363: warning: case value '0' not in enumerated type 'error_t'
        sysdeps/mach/hurd/setitimer.c: In function 'timer_thread':
        sysdeps/mach/hurd/setitimer.c:117: warning: case value '0' not in enumerated type 'error_t'
        sysdeps/mach/hurd/wait4.c: In function '__wait4':
        sysdeps/mach/hurd/wait4.c:40: warning: case value '0' not in enumerated type 'error_t'
        sysdeps/mach/hurd/fork.c: In function '__fork':
        sysdeps/mach/hurd/fork.c:423: warning: case value '0' not in enumerated type 'error_t'
        sysdeps/mach/hurd/spawni.c: In function '__spawni':
        sysdeps/mach/hurd/spawni.c:600: warning: case value '0' not in enumerated type 'error_t'
        sysdeps/mach/hurd/setpriority.c: In function 'setonepriority':
        sysdeps/mach/hurd/setpriority.c:66: warning: case value '0' not in enumerated type 'error_t'
        sysdeps/mach/hurd/ioctl.c: In function 'send_rpc':
        sysdeps/mach/hurd/ioctl.c:177: warning: case value '0' not in enumerated type 'error_t'
        sysdeps/mach/hurd/ioctl.c: In function '__ioctl':
        sysdeps/mach/hurd/ioctl.c:306: warning: case value '0' not in enumerated type 'error_t'

    [[!message-id "20120723195143.7F8142C0B9@topped-with-meat.com"]].

  * 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 gcc install fetch coulomb.SCHWINGE

TODO.

<!--
    $ diff -wu <(ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && cat hurd/master.build/log_install | sed -e "s%\(/media/data\)\?${PWD}%[...]%g"' | sed -f open_issues/gdb/log_install-linux.sed) <(ssh coulomb.SCHWINGE 'cd tmp/gdb/ && cat hurd/master.build/log_install | sed "s%\(/media/erich\)\?${PWD}%[...]%g"' | sed -f open_issues/gdb/log_install-hurd.sed) > open_issues/gdb/log_install.diff

[[log_install.diff]].

  * `libtool: finish`: `ldconfig` is not run for the Hurd.

-->


# Testsuite

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

This needs roughly X min on kepler.SCHWINGE and 60 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.

<!--
    $ ssh kepler.SCHWINGE 'cd tmp/source/gdb/ && sed < hurd/master.build/gdb/testsuite/gdb.sum -e "s%\(/media/data\)\?${PWD}%[...]%g"' > open_issues/gdb/sum_linux
    $ ssh coulomb.SCHWINGE 'cd tmp/gdb/ && sed < hurd/master.build/gdb/testsuite/gdb.sum -e "s%\(/media/erich\)\?${PWD}%[...]%g"' > open_issues/gdb/sum_hurd

Comparing the results files, [[sum_linux]] to [[sum_hurd]]:

    $ diff -u -F ^Running open_issues/gdb/sum_linux open_issues/gdb/sum_hurd > open_issues/gdb/sum.diff

[[open_issues/gdb/sum.diff]].
-->


## Analysis

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

There is quite a baseline of failures.


### Additional Failures 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

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

        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 fail with:

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

    [[packaging_libpthread]].

  * `io/ftwtest`, `posix/globtest`, `iconvdata/iconv-test`, `intl/tst-gettext`,
    `malloc/tst-mtrace`, `elf/tst-pathopt`, `iconvdata/tst-tables`,
    `grp/tst_fgetgrent`, `dlfcn/tststatic`, `dlfcn/tststatic2`,
    `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.

  * `posix/tst-getconf`

    Ends with:

        getconf POSIX_ALLOC_SIZE_MIN /: /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486/posix/getconf: pathconf: /: Invalid argument

  * `dlfcn/tststatic`, `dlfcn/tststatic2`

    No output, SEGFAULT.

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

    SIGSEGV.

  * `rt-tst-aio2`, `rt-tst-aio3`, `rt/tst-aio10`, `rt/tst-aio9`

        /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10.o: In function `do_test':
        tst-aio10.c:(.text+0x1b): undefined reference to `pthread_self'
        tst-aio10.c:(.text+0x78): undefined reference to `pthread_barrier_init'
        tst-aio10.c:(.text+0xf7): undefined reference to `pthread_create'
        tst-aio10.c:(.text+0x10b): undefined reference to `pthread_barrier_wait'
        /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10.o: In function `tf':
        tst-aio10.c:(.text+0x5ae): undefined reference to `pthread_barrier_wait'
        tst-aio10.c:(.text+0x5ef): undefined reference to `pthread_kill'
        collect2: ld returned 1 exit status
        make[2]: *** [/home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486.O/rt/tst-aio10] Error 1

  * `rt/tst-mqueue3`, `rt/tst-mqueue6`,
    `rt/tst-mqueue8`, `elf/tst-thrlock`, `rt/tst-timer3`,
    `nss//libnss_test1.so`

    Compilation: missing `pthread_attr_init`, `pthread_barrier_init`,
    `pthread_create`, etc.

  * `elf/tst-audit1`, `elf/tst-audit2`

    SIGKILL.

  * `inet/tst-ether_line`

        tst-ether_line.c: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]].

  * `gmon/tst-sprofil`

        Floating point exception

  * `posix/bug-regex31-mem`, `posix/tst-fnmatch-mem`

    *output* files: some memory not freed.

  * `assert/test-assert.out`

    Fails sometimes...

  * `stdlib/bug-getcontext.out`

        getcontext failed, errno: 1073741902.

    Is not implemented; see above.  In 8958805c11c741d9211e20612c86271d906c9a0b
    testing, `stdlib/bug-getcontext.out` now says: *Skipping test; no support
    for FP exceptions.*, in cba1c83ad62a11347684a9daf349e659237a1741 testing,
    it's back to the previous failure.

  * `elf/tst-unique3lib.so`, `elf/tst-unique3lib2.so`, `elf/tst-unique4lib.so`

    Only with GCC 4.4; no longer with 4.5 or 4.6:

        /home/thomas/tmp/glibc/tschwinge/Roger_Whittaker.build-gcc-4.4-486/elf/tst-unique3lib.os:(.data.DW.ref.__gxx_personality_v0[DW.ref.__gxx_personality_v0]+0x0): undefined reference to `__gxx_personality_v0'

  * `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.

  * `posix/tst-waitid.out`

    Fails sometimes (is listed in Debian eglibc-2.13-21's
    `expected-results-i486-gnu-libc`).

  * `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/tst-secure-getenv.out`

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

  * `elf/tst-array*`

    Failures also seen on GNU/Linux; [[!message-id
    "50950082.1070906@df1tl.local.here"]].

        gcc-4.6 tst-array1.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/
        gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1  -Wl,-dynamic-linker=/lib/ld.so.1   -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486
        [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[
        cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1.out tst-array1.exp > /dev/null
        make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1.out] Error 1
        gcc-4.6 tst-array2.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/
        gcc-4.6 tst-array2dep.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes   -fPIC       -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc
        gcc-4.6   -shared -static-libgcc  -Wl,-dynamic-linker=/lib/ld.so.1 -Wl,-z,defs -B[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/csu/  -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both  -L[...]/tschwinge/Roger_Whittaker.build-gcc-4.6
        gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array2  -Wl,-dynamic-linker=/lib/ld.so.1   -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486
        [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[
        cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array2.out tst-array2.exp > /dev/null
        make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array2.out] Error 1
        gcc-4.6 tst-array3.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/
        gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array3  -Wl,-dynamic-linker=/lib/ld.so.1   -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486
        [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[
        cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array3.out tst-array1.exp > /dev/null
        make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array3.out] Error 1
        gcc-4.6 tst-array4.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/
        gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array4  -Wl,-dynamic-linker=/lib/ld.so.1   -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486
        [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[
        cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array4.out tst-array4.exp > /dev/null
        make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array4.out] Error 1

    `tst-array5` passes.

        gcc-4.6 tst-array1-static.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
        gcc-4.6 -nostdlib -nostartfiles -static -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static    [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/csu/crt0.o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/csu/crti
        [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static > [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static.out
        cmp [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static.out tst-array1.exp > /dev/null
        make[2]: *** [[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1-static.out] Error 1

    `tst-array5-static` passes.


## OLD

`configure --without-cvs --prefix= --disable-profile --build=i486-gnu
--host=i486-gnu`

`make -k check` changes from 538603af899057a9ef9583cc447804ec602a45e5 to
c9fd33ef070def49c078c94f8d9bc9f8a8e267f7.

Configured with `--prefix=/usr` instead of `--prefix=`.

Resolved failures:

  * localedata/tst_mblen.out
  * localedata/tst_mbrlen.out
  * localedata/tst_mbrtowc.out
  * localedata/tst_mbsrtowcs.out
  * localedata/tst_mbstowcs.out
  * localedata/tst_mbtowc.out
  * localedata/tst_swscanf.out
  * localedata/tst_wcrtomb.out
  * localedata/tst_wcsrtombs.out
  * localedata/tst_wcstombs.out
  * localedata/tst_wctob.out
  * localedata/tst_wctomb.out
  * localedata/bug-iconv-trans.out
  * localedata/tst-wctype.out
  * math/test-float.out
  * math/test-double.out
  * posix/tst-vfork3-mem
  * io/tst-mkdirat.out

New:

  * A lot of `error while loading shared libraries: libmachuser.so.1: cannot
    open shared object file: No such file or directory`.  Is it perhaps picking
    that library up from `$prefix/lib/`?

    New failures; likely due to that:

      * iconvdata/iconv-test.out
      * iconvdata/tst-tables.out
      * malloc/tst-mtrace.out
      * grp/tst_fgetgrent.out
      * posix/globtest.out
      * posix/wordexp-tst.out
      * io/ftwtest.out
      * elf/tst-pathopt.out

    Changed failures; likely due to that:

      * debug/tst-chk4.out / debug/tst-chk5.out

            -error while loading shared libraries: libstdc++.so.6: cannot open shared object file: No such file or directory
            +error while loading shared libraries: libpthread-stubs.so.0: cannot open shared object file: No such file or directory

---

Changes to b367d4f996512af6841c3cefdb943cb0a826a6a1: nothing interesting.

---

Changes to b85c54a1f7e5241c1ef99dfeaecbd1bf4117564f: nothing interesting.

New failures:

  * posix/bug-glob3.out (SEGFAULT; but also on Linux)
  * wctype/bug-wctypeh.o (compile error; but also on Linux)