I'm working on it but ...
linuxbios_c.o: In function `displayinit': linuxbios_c.o(.text+0x3d6): undefined reference to `get_option' linuxbios_c.o: In function `remove_logical_cpus': linuxbios_c.o(.text+0xc57): undefined reference to `get_option' linuxbios_c.o: In function `sizeram': linuxbios_c.o(.text+0x20ae): undefined reference to `get_option' linuxbios_c.o: In function `i786_cpufixup': linuxbios_c.o(.text+0x2442): undefined reference to `get_option' linuxbios_c.o: In function `mainboard_fixup': linuxbios_c.o(.text+0x25f6): undefined reference to `get_option' linuxbios_c.o(.text+0x2621): more undefined references to `get_option' follow linuxbios_c.o: In function `ich3_rtc_init': linuxbios_c.o(.text+0x5cb8): undefined reference to `rtc_init' collect2: ld returned 1 exit status make: *** [linuxbios_c] Error 1
I'm looking.
ron
Greetings,
You need: option CONFIG_MC146818RTC=1 to fix that.
G'day, sjames
On Mon, 21 Apr 2003, Ronald G. Minnich wrote:
I'm working on it but ...
linuxbios_c.o: In function `displayinit': linuxbios_c.o(.text+0x3d6): undefined reference to `get_option' linuxbios_c.o: In function `remove_logical_cpus': linuxbios_c.o(.text+0xc57): undefined reference to `get_option' linuxbios_c.o: In function `sizeram': linuxbios_c.o(.text+0x20ae): undefined reference to `get_option' linuxbios_c.o: In function `i786_cpufixup': linuxbios_c.o(.text+0x2442): undefined reference to `get_option' linuxbios_c.o: In function `mainboard_fixup': linuxbios_c.o(.text+0x25f6): undefined reference to `get_option' linuxbios_c.o(.text+0x2621): more undefined references to `get_option' follow linuxbios_c.o: In function `ich3_rtc_init': linuxbios_c.o(.text+0x5cb8): undefined reference to `rtc_init' collect2: ld returned 1 exit status make: *** [linuxbios_c] Error 1
I'm looking.
ron
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Mon, 21 Apr 2003, steven james wrote:
option CONFIG_MC146818RTC=1 to fix that.
yeah, that did it. But what changed that broke the build, which was working until now?
ron
Probably removing i386isms for the PPC port. Sorry.
Greg
At 11:00 AM -0600 21/4/03, Ronald G. Minnich wrote:
On Mon, 21 Apr 2003, steven james wrote:
option CONFIG_MC146818RTC=1 to fix that.
yeah, that did it. But what changed that broke the build, which was working until now?
ron
Linuxbios mailing list Linuxbios@clustermatic.org http://www.clustermatic.org/mailman/listinfo/linuxbios
On Mon, 21 Apr 2003, Greg Watson wrote:
Probably removing i386isms for the PPC port. Sorry.
can you undo this? let's talk about how.
ron
"Ronald G. Minnich" rminnich@lanl.gov writes:
On Mon, 21 Apr 2003, Greg Watson wrote:
Probably removing i386isms for the PPC port. Sorry.
can you undo this? let's talk about how.
A couple of thoughts the option can be enabled by default, to the x86 build.
And the fact that get_option is so tightly tied to that particular piece of hardware may be a bug.
My question is why was the option needed?
That general piece of code was initially taken from the alpha kernel tree, so it is for more than just x86, and the code should compile on multiple platforms.
And if nothing referenced the code it should not have been linked in. So I don't see where the previous state of affairs should be a problem.
Eric
On 21 Apr 2003, Eric W. Biederman wrote:
A couple of thoughts the option can be enabled by default, to the x86 build.
I was wondering if we shouldn't enable it for all builds, as this hardware is so common, and individual mainboards can turn it off. The other option is a quick patch to almost all mainboard files to enable it.
Comments?
ron
I prefer Eric's approach of only enabling it for x86 builds, since it is really x86 specific.
Greg
At 3:24 PM -0600 21/4/03, ron minnich wrote:
On 21 Apr 2003, Eric W. Biederman wrote:
A couple of thoughts the option can be enabled by default, to the x86 build.
I was wondering if we shouldn't enable it for all builds, as this hardware is so common, and individual mainboards can turn it off. The other option is a quick patch to almost all mainboard files to enable it.
Comments?
ron
Greg Watson gwatson@lanl.gov writes:
I prefer Eric's approach of only enabling it for x86 builds, since it is really x86 specific.
Greg where did you run into problems with that code?
I just want to understand. Because that is code like the serial code. It started on x86 but has been spotted on other platforms.
Eric
On Mon, 21 Apr 2003, Greg Watson wrote:
I prefer Eric's approach of only enabling it for x86 builds, since it is really x86 specific.
but it's not. It was on the alpha.
I think it is mainboard specific; should we enable in the mainboard file?
ron
ron minnich rminnich@lanl.gov writes:
On Mon, 21 Apr 2003, Greg Watson wrote:
I prefer Eric's approach of only enabling it for x86 builds, since it is really x86 specific.
but it's not. It was on the alpha.
I think it is mainboard specific; should we enable in the mainboard file?
But the code is in a library so unless it is referenced it should compile but not be used.
Which is why it really confused me that greg had problems with it.
Eric
On 21 Apr 2003, Eric W. Biederman wrote:
But the code is in a library so unless it is referenced it should compile but not be used.
Which is why it really confused me that greg had problems with it.
good point. Greg, was the issue that the code would not compile or you just did not want it in there on PPC?
ron
At 4:02 PM -0600 21/4/03, ron minnich wrote:
On 21 Apr 2003, Eric W. Biederman wrote:
But the code is in a library so unless it is referenced it should compile but not be used.
Which is why it really confused me that greg had problems with it.
good point. Greg, was the issue that the code would not compile or you just did not want it in there on PPC?
ron
I only removed code that wouldn't compile for some reason. However I just tried it and it seems to compile ok now (apart from a warning about the unused variable i on line 139 :-), so put it back in if you want.
Greg
-
ebiederman＠lnxi.com -
Greg Watson -
ron minnich -
Ronald G. Minnich
-
steven james