"Ronald G. Minnich" <[EMAIL PROTECTED]> writes: > I am going to continue on this but it will be slow, I have a lot going on. > > The basic problem as I see it is that there is a little more magic in the > build process than it can stand, and specific platforms are breaking. > > In c_start.S and the constructed crt0.S there is a symbol called _start. > Same name.
Yes but in different binaries. c_start.S and crt0.S should never be linked together. There is one binary that is all of the code before ram is initialized. And another that is code after ram is initialized. > There are also, in these files, a set of symbols that on some > builds are needed for that build. So we need the .o from both files in > some builds. But the conflicting _start symbols are causing trouble. How? What links them together? > Simple attempts to change the name of the start symbol (e.g. change _start > in crt0.S to _machine_reset_start) lead to a host of other undefined > symbols, since once the _start is undefined, that file is not pulled in > and the symbols in that file are not resolved. > > I would rather not get into 'weak' symbols in assembly code files. > > Anyway, if anyone gets a chance to look at this and has some ideas ... let > me know. But we need to fix this situation. I need to see what the real problem that is linking together two different binaries before I can give a good suggestion. Eric _______________________________________________ Linuxbios mailing list [EMAIL PROTECTED] http://www.clustermatic.org/mailman/listinfo/linuxbios
