Re: [9fans] Linker and duplicate symbols

> It sounds like reboot wasn't a big concern for the raspberry Pi engineers. > Wow, weird. The normal case considered by the engineers is rebooting from the default kernel binary on the sd card (ie hard reset), which works fine both for linux and plan 9. The problem with 'fshalt -r' is that the

Re: [9fans] Linker and duplicate symbols

I wanted to check if the problem was pre existing or a result of a potentially bad merge on my part. It sounds like reboot wasn't a big concern for the raspberry Pi engineers. Wow, weird. Thanks for the suggestion. I'll try it out when/if they ever have the zero available in Canada for a

Re: [9fans] Linker and duplicate symbols

> Only weird problem is when I do fshalt -r. My pi2 goes unstable with panics > on reboot. Cold reset brings it back to normal. Sorry, I have seen this failure too, but only on pi3. If you run with *ncpu=1 the soft reboot seems to work reliably. But my scheme for rebooting from multicore state

Re: [9fans] Linker and duplicate symbols

Thanks Richard, I traced it down to a symbol being brought in from libc that brought in other symbols that collided with ones on the kernel. Btw, with your latest changes I have merged them in with the latest 9front and its running on my Pi 1 and Pi 2. Only weird problem is when I do fshalt

Re: [9fans] Linker and duplicate symbols

Thanks Steve, I will give these strategies a try. Chris > On Sep 2, 2016, at 6:34 PM, Steve Simon wrote: > > the linker rejects later instances of symbols if it had already found an > instance. the important point however is that this is done on a per file > basis if the

Re: [9fans] Linker and duplicate symbols

the linker rejects later instances of symbols if it had already found an instance. the important point however is that this is done on a per file basis if the symbol is in a library. the case where I have seen this is your code (the kernel code in this case) references another symbol which

Re: [9fans] Linker and duplicate symbols

Thanks Cinap, Richard, That makes sense and was probably obvious or in a man page somewhere. Chris > On Sep 2, 2016, at 12:12 PM, cinap_len...@felloff.net wrote: > > uses the first one it finds, so the order matters. its not unusual > for programs to override certain library function by

Re: [9fans] Linker and duplicate symbols

uses the first one it finds, so the order matters. its not unusual for programs to override certain library function by providing ther own version and putting them first in the object file list. this works only when the function you want to replace sits alone in his own object file (the smallest

Re: [9fans] Linker and duplicate symbols

> Is it that the linker prefers a symbol from a .5 file over the .a file? I believe it's supposed to pick the first one it finds. Object files and libraries are processed in the order in which they appear on the command line. On my system proc.5 appears before libc.a in the ld command, and

Re: [9fans] Linker and duplicate symbols

Thanks Richard, I tried outputting the echo of the ld command and it's linking all of the .5 files together along with the few archive files to produce the raw kernel file. I'll go hunting to see if there is some other unbound symbol. I think the reason why I'm confused is that I don't

Re: [9fans] Linker and duplicate symbols

> I have recently run into a problem when compiling the kernel where the linker > complains about duplicate symbols and fails. The symbol is sleep(), which is > exported in libc.a but is also exported in another file in port, but with > different parameters (both number and type). Shouldn't

[9fans] Linker and duplicate symbols

Hi All, I have recently run into a problem when compiling the kernel where the linker complains about duplicate symbols and fails. The symbol is sleep(), which is exported in libc.a but is also exported in another file in port, but with different parameters (both number and type). It's my