CDK on Athlon64 compilen

Kreuzuebersetzer, Diskussion über Änderungen im Tuxbox-CDK und Tuxbox-CVS
mcblack
Neugieriger
Neugieriger
Beiträge: 5
Registriert: Dienstag 15. März 2005, 11:02

CDK on Athlon64 compilen

Beitrag von mcblack »

Hi nochmal.

Also ich hab nachdem ich das ganze auf meinem Notebook probiert hab, und kläglich gescheitert bin, :-? mal versucht das ganze auf meiner Workstation zu compilieren.

System :

Athlon64 3,2 Ghz.
Asus A8V Deluxe Board
1 GB RAM

Gentoo Linux
2.6.9 er Kernel

Als Fehlermeldung hab ich folgendes bekommen :

sdeps/powerpc/powerpc32 -I../sysdeps/wordsize-32 -I../sysdeps/powerpc/soft-fp -I../sysdeps/powerpc/nofpu -I../sysdeps/powerpc -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -nostdinc -isystem /home/mcblack/dbox2/cdk/lib/gcc-lib/powerpc-tuxbox-linux-gnu/3.3.5/include -isystem /home/mcblack/tuxbox-cvs/cdk/linux/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -D'LOCALEDIR="/share/locale"' -D'LOCALE_ALIAS_PATH="/share/locale"' -o /home/mcblack/tuxbox-cvs/cdk/build_glibc/intl/bindtextdom.o
{standard input}: Assembler messages:
{standard input}:60: Error: illegal bitmask
make[4]: *** [/home/mcblack/tuxbox-cvs/cdk/build_glibc/intl/bindtextdom.o] Error 1
make[4]: Leaving directory `/home/mcblack/tuxbox-cvs/cdk/glibc-2.3.2/intl'
make[3]: *** [intl/subdir_lib] Error 2
make[3]: Leaving directory `/home/mcblack/tuxbox-cvs/cdk/glibc-2.3.2'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/mcblack/tuxbox-cvs/cdk/build_glibc'
make[1]: *** [.deps/glibc] Error 2
make[1]: Leaving directory `/home/mcblack/tuxbox-cvs/cdk'
make: *** [.deps/bootstrap] Error 2

Ich vermute mal das die hier verwendete CPU nicht mit dem alten glibc zurechtkommt.

Kann das jemand bestätigen ?

MfG

McBlack
JtG-Riker
Image-Team
Beiträge: 1015
Registriert: Freitag 7. Februar 2003, 18:37

Beitrag von JtG-Riker »

Hab das gleiche Problem, müsst mal jemand Fixen ;)

Aber es scheint kein Dev einen A64 zu haben

Riker
mcblack
Neugieriger
Neugieriger
Beiträge: 5
Registriert: Dienstag 15. März 2005, 11:02

Beitrag von mcblack »

Also wenn ein DEV interesse hat :

Ich könnte nen ssh Zugang auf meiner Kiste einrichten. Rechenzeit und Leitung wären kein Thema, da ich ne 3Mbit DSL Stande hab und der Rechner eh nicht viel genutzt wird.


Also wenn ein DEV interesse daran hat bitte per PM melden.

MfG

McBlack
the_moon
Einsteiger
Einsteiger
Beiträge: 223
Registriert: Samstag 25. Januar 2003, 11:18

Beitrag von the_moon »

Ka, ich das Problem bestätigen. Hab auch Athlon64 + suse9.2 frisch installiert.

Alles sieht sauber auser ein paar includes die zeigen auserhalb cdk Verzeichniss.

Code: Alles auswählen

powerpc-tuxbox-linux-gnu-gcc loadlocale.c -c -std=gnu99 -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -g3 -gdwarf-2 -mcpu=823 -meabi -mmultiple -mstring -pipe -Wa,-mppc -mpowerpc -msoft-float -mnew-mnemonics     [b]
-DLOCALE_PATH='"/lib/locale:/share/i18n"' 
-DLOCALEDIR='"/lib/locale"' -DLOCALE_ALIAS_PATH='"/share/locale"' -DCHARMAP_PATH='"/share/i18n/charmaps"' -DREPERTOIREMAP_PATH='"/share/i18n/repertoiremaps"' -DLOCSRCDIR='"/share/i18n/locales"' 
[/b]
-DHAVE_CONFIG_H -Iprograms -I../include -I. -I/home/georg/programing/dbox/cdk/build_glibc/locale -I.. -I../libio  -I/home/georg/programing/dbox/cdk/build_glibc -I../sysdeps/powerpc/powerpc32/elf -I../sysdeps/powerpc/elf -I../linuxthreads/sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../linuxthreads/sysdeps/unix/sysv/linux/powerpc -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/powerpc/powerpc32 -I../linuxthreads/sysdeps/powerpc -I../sysdeps/unix/sysv/linux/powerpc/powerpc32 -I../sysdeps/unix/sysv/linux/powerpc -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/powerpc -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/powerpc/powerpc32 -I../sysdeps/wordsize-32 -I../sysdeps/powerpc/soft-fp -I../sysdeps/powerpc/nofpu -I../sysdeps/powerpc -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic  -nostdinc -isystem /home/georg/programing/tuxbox/cdk/lib/gcc-lib/powerpc-tuxbox-linux-gnu/3.3.5/include -isystem /home/georg/programing/dbox/cdk/linux/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h       -o /home/georg/programing/dbox/cdk/build_glibc/locale/loadlocale.o
[b]
{standard input}: Assembler messages:
{standard input}:8634: Error: illegal bitmask
[/b]
make[3]: *** [/home/georg/programing/dbox/cdk/build_glibc/locale/loadlocale.o] Ошибка 1
make[3]: Leaving directory `/home/georg/programing/dbox/cdk/glibc-2.3.2/locale'
make[2]: *** [locale/subdir_lib] Ошибка 2
make[2]: Leaving directory `/home/georg/programing/dbox/cdk/glibc-2.3.2'
make[1]: *** [all] Ошибка 2
make[1]: Leaving directory `/home/georg/programing/dbox/cdk/build_glibc'
make: *** [.deps/glibc] Ошибка 2

Ich vermute alles anderes ist genau gleich wie bei anderen Prozessoren Typen. Vielleicht liegt es auch an dem Assembler. Ich weiss nicht, wird zum compilieren von glibc installierte in System gcc oder speziel dafür gebaute gcc?
the_moon
Einsteiger
Einsteiger
Beiträge: 223
Registriert: Samstag 25. Januar 2003, 11:18

Beitrag von the_moon »

Entschuldigung für mein stupid Deutsch. Ich bin etwas zu eilig gewesen.
the_moon
Einsteiger
Einsteiger
Beiträge: 223
Registriert: Samstag 25. Januar 2003, 11:18

Beitrag von the_moon »

Ah ja und ich meinte diese Zeilen und Pfade.




-DLOCALE_PATH='"/lib/locale:/share/i18n"'
-DLOCALEDIR='"/lib/locale"' -DLOCALE_ALIAS_PATH='"/share/locale"' -DCHARMAP_PATH='"/share/i18n/charmaps"' -DREPERTOIREMAP_PATH='"/share/i18n/repertoiremaps"' -DLOCSRCDIR='"/share/i18n/locales/"'
the_moon
Einsteiger
Einsteiger
Beiträge: 223
Registriert: Samstag 25. Januar 2003, 11:18

Beitrag von the_moon »

Also, ich habe ein bischen nachgeforscht in dem ich mir assembler code beim gcc generiren lassen habe.

Es sieht so aus, Fehlerquelle bold markiert.
_nl_load_locale:
.LFB58:
.loc 1 134 0
stwu 1,-176(1)
.LCFI3:
mflr 0
stw 0,180(1)
.LCFI4:
stmw 22,136(1)
.LCFI5:
.loc 1 143 0
.LBB6:

li 0,0
.loc 1 134 0
mr 25,3
.loc 1 140 0
li 23,1
.loc 1 145 0
lwz 3,0(3)
.loc 1 134 0
mfcr 12
mr 31,1
.LCFI6:
.loc 1 143 0
stw 0,8(25)
.loc 1 134 0
mr 22,4
.loc 1 142 0
stw 23,4(25)
.loc 1 145 0
li 4,0
.loc 1 134 0
stw 12,132(1)
.LCFI7:
.loc 1 145 0
bl __open
.loc 1 146 0
cmpwi 0,3,0
.loc 1 145 0
mr 28,3
.loc 1 146 0
blt- 0,.L22
.loc 1 150 0
addi 30,31,16
li 3,3
mr 4,28
mr 5,30
bl __fxstat64
cmpwi 0,3,0
blt- 0,.L25
.loc 1 156 0
lwz 0,32(31)
rlwinm 0,0,0,16,19
cmpwi 0,0,16384
beq- 0,.L45
.L26:
.loc 1 182 0
bl __errno_location
.loc 1 192 0
lwz 4,68(31)
.loc 1 182 0
mr 27,3
.loc 1 192 0
li 5,1
li 3,0
li 6,2
mr 7,28
li 8,0
.loc 1 182 0
lwz 24,0(27)
.loc 1 192 0
bl __mmap
.loc 1 194 0
cmpwi 7,3,0
cmpwi 0,3,4660
.loc 1 192 0
mr 29,3
.loc 1 194 0
mfcr 26
rlwinm 26,26,28,0xf0000000
beq- 0,.L46
.L29:
.loc 1 228 0
mr 3,28
bl __close
.loc 1 230 0
mtcrf 128,26
beq- 0,.L22
.loc 1 234 0
lwz 5,68(31)
mr 3,22
mr 4,29
bl _nl_intern_locale_data
.loc 1 235 0
cmpwi 0,3,0
beq- 0,.L47
.loc 1 246 0
li 0,0
.loc 1 249 0
stw 3,8(25)
.loc 1 246 0
stw 0,0(3)
.loc 1 247 0
stw 23,12(3)
.loc 1 250 0
.L22:
Und das ist die Funktion von dem das Assembler Code entstanden.

Code: Alles auswählen

_nl_load_locale (struct loaded_l10nfile *file, int category)
{
  int fd;
  void *filedata;
  struct stat64 st;
  struct locale_data *newdata;
  int save_err;
  int alloc = ld_mapped;

  file->decided = 1;
  file->data = ((void *)0);

  fd = __open (file->filename, 00);
  if (__builtin_expect (fd, 0) < 0)

    return;

  if (__builtin_expect (__fxstat64 (3, fd, &st), 0) < 0)
    {
    puntfd:
      __close (fd);
      return;
    }
  if (__builtin_expect (((((st.st_mode)) & 0170000) == (0040000)), 0))
    {


      char *newp;
      size_t filenamelen;

      __close (fd);

      filenamelen = strlen (file->filename);
      newp = (char *) __builtin_alloca (filenamelen + 5 + _nl_category_name_sizes[category] + 1);

      (__extension__ (__builtin_constant_p (_nl_category_names[category]) && __builtin_constant_p (_nl_category_name_sizes[category] + 1) && ((size_t)(const void *)((_nl_category_names[category]) + 1) - (size_t)(const void *)(_nl_category_names[category]) == 1) && _nl_category_name_sizes[category] + 1 <= 8 ? __builtin_memcpy ((__extension__ (__builtin_constant_p ("/SYS_") && __builtin_constant_p (5) && ((size_t)(const void *)(("/SYS_") + 1) - (size_t)(const void *)("/SYS_") == 1) && 5 <= 8 ? __builtin_memcpy ((__extension__ (__builtin_constant_p (file->filename) && __builtin_constant_p (filenamelen) && ((size_t)(const void *)((file->filename) + 1) - (size_t)(const void *)(file->filename) == 1) && filenamelen <= 8 ? __builtin_memcpy (newp, file->filename, filenamelen) + (filenamelen) : __mempcpy (newp, file->filename, filenamelen))), "/SYS_", 5) + (5) : __mempcpy ((__extension__ (__builtin_constant_p (file->filename) && __builtin_constant_p (filenamelen) && ((size_t)(const void *)((file->filename) + 1) - (size_t)(const void *)(file->filename) == 1) && filenamelen <= 8 ? __builtin_memcpy (newp, file->filename, filenamelen) + (filenamelen) : __mempcpy (newp, file->filename, filenamelen))), "/SYS_", 5))), _nl_category_names[category], _nl_category_name_sizes[category] + 1) + (_nl_category_name_sizes[category] + 1) : __mempcpy ((__extension__ (__builtin_constant_p ("/SYS_") && __builtin_constant_p (5) && ((size_t)(const void *)(("/SYS_") + 1) - (size_t)(const void *)("/SYS_") == 1) && 5 <= 8 ? __builtin_memcpy ((__extension__ (__builtin_constant_p (file->filename) && __builtin_constant_p (filenamelen) && ((size_t)(const void *)((file->filename) + 1) - (size_t)(const void *)(file->filename) == 1) && filenamelen <= 8 ? __builtin_memcpy (newp, file->filename, filenamelen) + (filenamelen) : __mempcpy (newp, file->filename, filenamelen))), "/SYS_", 5) + (5) : __mempcpy ((__extension__ (__builtin_constant_p (file->filename) && __builtin_constant_p (filenamelen) && ((size_t)(const void *)((file->filename) + 1) - (size_t)(const void *)(file->filename) == 1) && filenamelen <= 8 ? __builtin_memcpy (newp, file->filename, filenamelen) + (filenamelen) : __mempcpy (newp, file->filename, filenamelen))), "/SYS_", 5))), _nl_category_names[category], _nl_category_name_sizes[category] + 1)));

	  fd = __open (newp, 00);
      if (__builtin_expect (fd, 0) < 0)
        return;

      if (__builtin_expect (__fxstat64 (3, fd, &st), 0) < 0)
        goto puntfd;
    }
  save_err = (*__errno_location ());

#define MAP_COPY MAP_PRIVATE

  filedata = __mmap ((caddr_t) 0, st.st_size,
                     0x1, 0x000|0x002, fd, 0);
  if (__builtin_expect (filedata == ((void *) -1), 0))
    {
      if (__builtin_expect ((*__errno_location ()), 38) == 38)
        {
          alloc = ld_malloced;
          filedata = malloc (st.st_size);
          if (filedata != ((void *)0))
            {
              off_t to_read = st.st_size;
              ssize_t nread;
              char *p = (char *) filedata;
              while (to_read > 0)
                {
                  nread = __read (fd, p, to_read);
                  if (__builtin_expect (nread, 1) <= 0)
                    {
                      free (filedata);
                      if (nread == 0)
                        ((*__errno_location ()) = (22));
                      goto puntfd;
                    }
                  p += nread;
                  to_read -= nread;
                }
              ((*__errno_location ()) = (save_err));
            }

        }
    }

  __close (fd);

  if (__builtin_expect (filedata == ((void *)0), 0))

    return;

  newdata = _nl_intern_locale_data (category, filedata, st.st_size);
  if (__builtin_expect (newdata == ((void *)0), 0))

    {

      if (alloc == ld_mapped)
        __munmap ((caddr_t) filedata, st.st_size);

      return;
    }


  newdata->name = ((void *)0);
  newdata->alloc = alloc;

  file->data = newdata;
}
Leider weiter meine Assembler Kenntnisse sind nicht ausreichend. Aber ich vermute es liegt and dem statement, nämlich "(void*)-1"
if (__builtin_expect (filedata == ((void *) -1), 0))
Oder an etwas in der Art.

Ich würde mich sehr freuen auf ein Workarond für das Problem oder ein Tip. Wenn jemand Lust und Ahnung hat ich kann die drei loadlocale Dateien per mail zu senden.

loadlocale.c // sources
loadlocale.i //preprocessed sources
loadlocale.s //assembler code

Danke in voraus
Houdini
Developer
Beiträge: 2183
Registriert: Mittwoch 10. Dezember 2003, 07:59

Beitrag von Houdini »

üblicherweise sind die 'athlon64 incompatibilitäten' ein Problem mit dem long datentyp, d.h. ein long var ist dann auf einmal 64 bit und nicht mehr 32.

the_moon liegt da glaub ich schon ganz richtig
vgl: http://www.google.de/search?q=%22Error% ... al+bitmask

edit:
ein Blick in
http://pds.twi.tudelft.nl/vakken/in1200 ... lwinm.html
bestätigt obige Annahmen
Der Wert 0xf0000000 ist falsch, er sollte nicht größer als 32 sein
the_moon
Einsteiger
Einsteiger
Beiträge: 223
Registriert: Samstag 25. Januar 2003, 11:18

Beitrag von the_moon »

Ich habe versucht linux kernel sources zu patchen, die ich in meinem System installiert habe und die, die bei der CDK scripts geholt und installiert werden. ich habe ppc-opt.c Datei geändert, wie es hier beschrieben wurde.

http://mail-index.netbsd.org/tech-toolc ... /0000.html

Ergebnis - nichts. :(

Habe versucht UML linux unter Suse zu starten - geht auch nicht. :)

Und jetzt habe ich ein 32 bit computer zum Leben erweckt und werde da CDK zuzammenbauen.

Wahrscheinlich so ist es am einfachsten.:)
the_moon
Einsteiger
Einsteiger
Beiträge: 223
Registriert: Samstag 25. Januar 2003, 11:18

Beitrag von the_moon »

Also, ich habe so gemacht.

Ich habe zur Zeit auf meinem Rechner gentoo linux mit march=k8 kompilirt. Bei mir tritt das Fehler auch auf.

Ich habe konoppix gestarted und CDK vollstaendig kompiliert.

Jetzt kann ich auch unter Gentoo herum basteln und kompilieren, solange ich gcc und g++ nicht anfasse.