I'm getting the undefined symbol before doing anything related to the new platform. I am in the early steps of porting rump kernels over and as of right now, nothing within the rump kernel (neither the application layer nor the hypercall interface) are calling anything from the new platform.
I can reproduce the undefined symbol simply by following my current tool chain for any of my applications. Rumprun-bmk-cc -> rumpbake. The output of rumpbake is what has the undefined symbol __cerror. This does not prevent the applicaiton from running. The apps work fine. It is just if I tried to link these with some other code base it will then yell at me. Repeating the problem is easy for me, I just tested it a couple times and it is still there. I can't think of anything too relevant to share as it seems to be just the generic tool chain that is producing it. On Thu, Jul 9, 2015 at 4:10 PM, Antti Kantee <[email protected]> wrote: > On 09/07/15 19:48, Robert Gifford wrote: > >> >>> Hmm, apparently there are a few routines in the libc we ship which try to >>> use __cerror. Are you by chance building something which calls >>> resumecontext()? >>> >>> >> As for now, the "application", if you can really call it that is simply a >> main with a return. Nothing I am building is calling it to my knowledge. >> > > You mentioned "with some booter code from a platform I'm attempting to > support", so thought that was it. Unless you mean you added that code to > the kernel side of things. > > I have a plan to try to fix the problem, but it would first be nice to be > able to repeat the problem so that I can be sure it's gone; the fix needs > to go into NetBSD and the cycle of pulling in code from NetBSD is rather > labor-intensive. > > Can you paste anything you think is relevant: command output, etc.? > >
