DM7025 CVS Build auf AMD64 (SuSE)

    Hallo, ich hab versucht, ein CVS image für die 7025 zu kompilieren,
    dabei fliegt er mir aber bei der Koimpilierung von enigma2 raus,
    weil der datentyp für long nicht stimmt (in Pyport.h).
    Anscheinend werden hier die datentypen vom pc mit denen vom zielsystem vermischt ...
    Hab die gleiche Kompilierung unter selben suse, nur 32 bit laufenlassen (dauert ewig, stöhn) und da lief bei gleicer prozedur alles durch.


    Hat sonst einer versucht, auf einem 64 bit Rechner zu kompilieren?


    Grüsse


    Wolpi


    hier noch das logfile als attachement

    Jo hat ich auch:


    in der pyport.h den Wert auf den SOLL Stand bringen (Verzweifelungsversuch) dann kompilierts durch und das Image ist durchaus lauffähig :winking_face:

    __________________________________________
    Science is nothing else than reverse Engineering Nature !


    * 1. DM 7025 SS
    * 2. DM 7020 S
    * 3. Micronik TV Box 1200S, MAM600
    * Astra 19.2° E
    * Hotbird 13.0° E schielend

    hallo mordillo,


    danke für den hinweis (scheins gibts nicht viele mit 64bit maschinen hier ..)


    ich hab in den letzten tagen noch rumprobiert, und die ursache etwas genauer analysiert.
    Scheint ein configure problem bei enigma zu sein ...


    Habe es mal als Bug bei enigma2 eingestellt (hier), vielleicht finded sich da ja jemand, ders beheben kann.


    Grüsse
    Wolpi

    Einmal editiert, zuletzt von wolpi ()

    hallo dieter,
    danke für den hinweis, hatte ich auch schon gefunden,
    der behebt vielleicht das symptom (die Fehlermeldung) aber nicht die Ursache (nämlich daß ein falsches Verzeichnis eingebunden wird ...)
    Er bindet dann halt das i686-linux/include/python2.4 verzeichnis ein, aber nicht das für mispel-linux.


    Ich habe hier ein 64bit userspace, also kompilier ich auch meine tools dafür. hat ja erstmal mit der zielplattform nix zu tun.


    floh: das configure von enigma fällt unter oe generell?


    Grüsse
    Wolpi

    Ich hab bei meinem 64bit Suse das gleiche Problemmit dem long :frowning_face:

    Zitat


    In file included from /home/bacwolf/dm7025/build/tmp/staging/x86_64-linux/include/python2.4/Python.h:55,
    from /home/bacwolf/dm7025/build/tmp/work/enigma2-1.0cvs20060323-r0/enigma2/lib/actions/action.h:10,
    from action.cpp:1:
    /home/bacwolf/dm7025/build/tmp/staging/x86_64-linux/include/python2.4/pyport.h:612:2: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
    ...


    an die local.conf hab ich auch gedacht

    ------------------------------------------------------
    DM800 HD (newnigma2/ooZooN)
    DM7025 160GB HDD | 256MB CF (newnigma2)
    DBox2 Nokia 2xI | Multicam (Newmake-CVS-Image)
    Maximum T85 mit 5 LNB (9,0°|13,0°|19,2°|23,5°|28,2°Ost)
    XBox360 20GB HDD (iXtreme 1.6)
    XBox 80GB (evoX/XBMC)
    FritzBox 7141 230GB HDD | 256MB USB (freetz-1.3)
    XDA Diamond (WM6.5)

    Optimal wäre es selbst ein Python-Include-Verzeichnis angeben zu können beim bauen von enigma2. Hatte am Anfang auch das Problem, dass ich es außerhalb des oe compilen wollte, er aber immer mein lokales Pythonverzeichnis genommen hat

    Kann mir mal bitte jemand sagen, über welches File ich ihm das "richtige" include-Verzeichnis beibringen kann? Ich krieg´s einfach nicht hin :loudly_crying_face:

    ------------------------------------------------------
    DM800 HD (newnigma2/ooZooN)
    DM7025 160GB HDD | 256MB CF (newnigma2)
    DBox2 Nokia 2xI | Multicam (Newmake-CVS-Image)
    Maximum T85 mit 5 LNB (9,0°|13,0°|19,2°|23,5°|28,2°Ost)
    XBox360 20GB HDD (iXtreme 1.6)
    XBox 80GB (evoX/XBMC)
    FritzBox 7141 230GB HDD | 256MB USB (freetz-1.3)
    XDA Diamond (WM6.5)

    das BUILD_ARCH = "i686" ist natürlich nur für 32bit userspace unter 64bit kernel. Da ist das auch dringend notwendig, sonst sollte man nochmal alles neu bauen.


    mit 64bit userspace hab ich keine ahnung - das kann auch ein bug sein. Ich wäre dann sehr dankbar für ein .diff :winking_face:


    Change or Move:
    build/tmp/staging/x86_64-linux/include/python2.4
    with
    build/tmp/staging/mipsel-linux/include/python2.4


    ..to my Slamd64 now enigma2 compile ok.
    Bye.

    Zitat

    Original von tmbinc
    das BUILD_ARCH = "i686" ist natürlich nur für 32bit userspace unter 64bit kernel. Da ist das auch dringend notwendig, sonst sollte man nochmal alles neu bauen.


    Mal ne (vielleicht dumme) Frage: Wie soll ich das bewerkstelligen, da die local.conf ja erst nach dem make... erstellt wird?

    ------------------------------------------------------
    DM800 HD (newnigma2/ooZooN)
    DM7025 160GB HDD | 256MB CF (newnigma2)
    DBox2 Nokia 2xI | Multicam (Newmake-CVS-Image)
    Maximum T85 mit 5 LNB (9,0°|13,0°|19,2°|23,5°|28,2°Ost)
    XBox360 20GB HDD (iXtreme 1.6)
    XBox 80GB (evoX/XBMC)
    FritzBox 7141 230GB HDD | 256MB USB (freetz-1.3)
    XDA Diamond (WM6.5)

    entweder durch eine änderung im Makefile, oder statt "make image" einfach "make all openembedded-update".


    dann die local.conf ändern, und dann "make image".

    alles klar - danke sehr

    ------------------------------------------------------
    DM800 HD (newnigma2/ooZooN)
    DM7025 160GB HDD | 256MB CF (newnigma2)
    DBox2 Nokia 2xI | Multicam (Newmake-CVS-Image)
    Maximum T85 mit 5 LNB (9,0°|13,0°|19,2°|23,5°|28,2°Ost)
    XBox360 20GB HDD (iXtreme 1.6)
    XBox 80GB (evoX/XBMC)
    FritzBox 7141 230GB HDD | 256MB USB (freetz-1.3)
    XDA Diamond (WM6.5)

    Having bought myself this new 64bit toy, I've had the opportunity to look a little bit closer into this problem of compiling enigma2 using an x86_64 architecture build machine.


    Zitat

    Original von tmbinc
    das BUILD_ARCH = "i686" ist natürlich nur für 32bit userspace unter 64bit kernel. Da ist das auch dringend notwendig, sonst sollte man nochmal alles neu bauen.


    mit 64bit userspace hab ich keine ahnung - das kann auch ein bug sein. Ich wäre dann sehr dankbar für ein .diff :winking_face:


    My conclusion so far is that there is indeed a bug in the build files for enigma2. The generated Makefile contains the following line (I've split it up to be readable):


    I've put the offending part in bold. The include files for the build system is used instead of the include files for the host system, and that just can't be right. The LDFLAGS

    Zitat

    LDFLAGS = -L/src/OpenEmbedded/build/tmp/staging/mipsel-linux/lib
    -Wl,-rpath-link,/src/OpenEmbedded/build/tmp/staging/mipsel-linux/lib -Wl,-O1 -pthread
    -L/src/OpenEmbedded/build/tmp/staging/x86_64-linux/lib/python2.4/config -lpython2.4

    is also wrong, but the fact that the mipsel directory contains the correct libraries saves us from this becoming a serious problem.


    I then looked for the source of the incorrect Makefile, and found the following lines in configure.ac


    The first of these two lines will run the python compiler and set some variables. The second line will expand upon this (in the AC_PYTHON_DEVEL macro in acinclude.m4) to set the include files and library paths. Running the build python to set the include- and library path for the host python library is, as the English say, "not even wrong".


    Unfortunately, I don't have a simple solution. I have a few ideas, though:
    [list=1]
    [*]Patch python so that a python.pc file can be assembled and installed in the correct directory. Then the python lib can be handled like any other pkgconfig-controlled library.
    [*]Change the acinclude.m4 file so that cross-compilation is detected, and a different strategy is used when it makes no sense to run python to find the values for the variables.
    [*]Hack the hell out of configure.ac. This would most likely break portability of enigma2 configuration, so it's probably not a good solution
    [/list=1]
    Before I invest more time in trying out any of these ideas, I thought I should check here to see if anybody has any better ideas. Also, it would be nice to hear what kind of fix would be acceptable to the enigma2 developers.


    Does anybody have any comments or suggestions?

    Last one, I think....


    I'm not 100% certain why the ppp-2.4.3-r0 package compiled OK before, while it now complains about missing crypt support. Anyway, upgrading to ppp-2.4.3-r1 from the org.openembedded.dev branch fixed the problem.


    With the previously posted patches to enigma2 and this upgrade of ppp, dreambox-image now builds on my machine (Suse 10.1, x86_64) without resorting to using i686 as the build architecture.