Mickey, thanks for all your answers! I'm not replying here to your answers that are clear to me. I'm only replying here to the points I am confused by.
Michael 'Mickey' Lauer <[EMAIL PROTECTED]> writes: > Joe Wells: >> > 1.) get your EZX-toolchain up and running with all necessary >> > libraries available you want to link against. >> >> I had been under the impression that the OpenEmbedded framework can >> help with building the compiler tools. Is this not true, or is there >> some reason why in this particular case OpenEmbedded does not help? > > That's right. Usually, OpenEmbedded builds the toolchain and this is > not necessary. However in your particular case there are two > problems: > 1.) You need to build a 100% compatible toolchain to build binaries > that link and work against your runtime libraries on the phone. It's > painful to recreate all what's necessary -- that's the reason why I > use a prebuilt toolchain. I'm expecting to have to make the headers for the libraries myself. I'm hoping that merely fetching the correct old versions of glibc and Qt/Embedded will go a long way towards solving that problem. I can use the libraries on the A780 to make dummy versions with the code portion zeroed out that will be good enough for linking. The above steps involve no risk of copyright violation. I can hopefully figure out the interface to any remaining symbols I need to use by reverse engineering (e.g., using strace, ltrace, etc.). Are these the kind of issues you mean or are there other completely different issues? > 2.) The EZX-toolchain as distributed by several sources is of > questionable legalty -- we are not going to allow these things to be > a direct part of OE. I suppose you mean Sam Revitch's customization for EZX of Dan Kegel's crosstool. I haven't yet investigated it (because I thought that maybe OpenEmbedded would be able to supply this need). What are the legal issues with it? If I am to succeed the way I want to succeed I will need to find a way around these issues. I would much rather make something others can use. >> Can someone explain the structure of the value of ASSUME_PROVIDED? > > That stuff tells OE to ASSUME that some dependencies are PROVIDED by > you and that OE doesn't need to build them. > > Please see the OE manual and the BitBake manual for those "basics" :) I am indeed reading them. I was confused by the particular package names you put in ASSUME_PROVIDED and why those particular names needed to be there. >> What is the difference between "gcc-cross-initial" and "gcc-cross"? > > Part of the toolchain creation. You can't build gcc in one run. See > "building gcc" on gcc.gnu.org for a (exhaustive) explanation... Why am I supposed to claim to have provided both of them? If I understand correctly, I will only provide the substitute for gcc-cross. Am I wrong? >> > 3.) integrate MPK as an additional package format. >> >> What is MPK? I haven't heard of this before. Do you mean the >> files with ".mpkg" extension? > > Yes. Apparantly those are just old-style ipks without a CONTROL > file, so not much to do for you in this direction :) Where do I need to make changes to integrate support for them? Once again, thanks very much for your help! -- Joe _______________________________________________ Oe mailing list [email protected] https://www.handhelds.org/mailman/listinfo/oe
