Re: [ECOS] Device Driver package link error

[Andrew Lunn <andrew at lunn dot ch>]

On Fri, Feb 08, 2008 at 01:29:33PM -0000, Steven Clugston wrote:
> I've been trying to write a generic TPU (Time Processor Unit) driver for the MPC555 based on Bob Koninckxx's Encoder driver.
> To do this I've tried to separate stuff that's specific to a particular TPU function such as quadrature decode for the encoder into separate files from the stuff that is generically required to setup and run the TPU.
> 
> So in my file structure I now have:
> 
> packages/devs/tpu/mpc555/current/src/tpu.c
> packages/devs/tpu/mpc555/current/src/tpu.h
> packages/devs/tpu/mpc555/current/src/dev_encoder.c
> packages/devs/tpu/mpc555/current/cdl/tpu_mpc555.cdl
> 
> This is a first step towards being able to enable other functions such as PWM and DIO by having the corresponding source files with only the code specific to those TPU functions. By TPU function I mean the microcode that is loaded into each TPU channel for it to perform a specific 'function' not a single C code function. So I might additionally have dev_pwm.c and dev_dio.c as well. Each of these functions would be enabled as CDL components of the TPU device and have their own interfaces in the IO layer such as /dev/enc1 and /dev/pwm1 etc.
> 
> I've added to the package level of tpu_mpc555.cdl:
> 
> compile -library=libextras.a tpu.c dev_encoder.c
> 
> And I've also tried separate entries:
> 
> compile -library=libextras.a tpu.c 
> compile -library=libextras.a dev_encoder.c
> 
> The problem I've facing is are link errors at the appication link stage, such as:
> 
> Project_install/lib/extras.o(.text.tpu3_encoder_lookup+0x64): undefined reference to 'tpu_disable'
> 
> Where tpu_disable is a function declared in tpu.h and the function entry in tpu.c, but called from dev_encoder.c which includes the header tpu.h.
> 
> I've tried an objdump on libextras.o and the functions such as tpu_disable are present, but the linker doesn't seem to find them.
> Is this a name managling problem, or am I being na?ve in my understanding of the linking process?

It could be an ordering problem. I've seen the linker not go back to a
library it has processed once to find symbols it needs because of an
object file later in the sequence. 

Humm. 

libextra is a bit special. At the end of the build process it is
linked to make install/lib/extra.o. See if you symbols are in extra.o,
since that is what is actually linked to the application.

      Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss