Kai Germaschewski wrote:
>
> On Thu, 14 Jun 2001, Brad Hards wrote:
<snip>
> > When I do a "strings hcd.o", I see the following:
> > __VERSIONED_SYMBOL(usb_hcd_pci_probe)
> > __VERSIONED_SYMBOL(usb_hcd_pci_remove)
> > __VERSIONED_SYMBOL(usb_hcd_pci_suspend)
> > __VERSIONED_SYMBOL(usb_hcd_pci_resume)
> > __VERSIONED_SYMBOL(usb_hcd_giveback_urb)
>
> There's two possible explanations for this: module versioning
> dependencies are broken, the only reliable way to fix this is to make
> mrproper and rebuild. The other one is the objects which are exporting
> symbols are not listed appropriately in export-objs. I think you've got
> the second problem. You get the list for export-objs by "grep
> EXPORT_SYMBOL *.c" and replacing .c -> .o. However, your Makefiles are
> broken and handling things differently from the rest of the kernel, which
> is not good (and may cause all sorts of problems).
I've tried rebuilding from mrproper, that makes no difference.
So I agree with the the analysis.
> I'm appending a patch agains current sf CVS (usb and hcd), which gets
> things more in line with how it's done usually.
While the hcd stuff is current, usb is way out of date. So it won't apply
correctly, to say the current -ac release. I've had a hack at taking your
patch and applying it more generally, see attached file. I haven't looked at
the hcd aspects just yet, since I thought I might try to clean up the existing
code first.
> [Patch to usb CVS]
<snip>
> + dep_tristate ' UHCI HCD support (EXPERIMENTAL)' CONFIG_UHCI_HCD $CONFIG_USB
>$CONFIG_EXPERIMENTAL
This doesn't exist yet, it is just stubbed into the Makefile. No issue though.
<snip>
> I removed the CONFIG_USB_HCD thing, we now always enter drivers/usb/hcd.
> (It's not a problem even if we didn't select any host controller, it only
> has a tiny performance penalty in this case. I suppose it doesn't really
> much sense to compile USB without host controller support, anyway)
OK with the logic, although there will likely be host controllers that don't
use the unified hcd architecture for a while to come...
<snip>
> +list-multi := usbcore.o
> +usbcore-objs := usb.o usb-debug.o hub.o
> +usbcore-objs-$(CONFIG_USB_DEVICEFS) += devio.o inode.o drivers.o devices.o
> +usbcore-objs += $(usbcore-objs-y)
OK, I think I see how this works for the bool case (see hid code in the
attached Makefile, but I need some more help with a dep_tristate that uses
multi files. The modified makefile is attached, but these are the relevant
parts:
ifneq ($(CONFIG_USB_PWC),n)
export-objs += pwc-uncompress.o
list-multi += pwc.o
endif
pwc-objs := pwc-if.o pwc-misc.o pwc-ctrl.o pwc-uncompress.o
obj-$(CONFIG_USB_PWC) += pwc.o
pwc.o: $(pwc-objs)
$(LD) -r -o $@ $(pwc-objs)
It doesn't seem very clean.
Can I simply:
export-objs := usb.o pwc-uncompress.o
list-multi := usbcore.o hid.o pwc.o
pwc-objs := pwc-if.o pwc-misc.o pwc-ctrl.o pwc-uncompress.o
obj-$(CONFIG_USB_PWC) += pwc.o
pwc.o: $(pwc-objs)
$(LD) -r -o $@ $(pwc-objs)
Does this handle not building pwc.o (and all the linked code) if
CONFIG_USB_PWC=n? Are there any side effects of doing this?
Thanks very much for the help so far, I really do appreciate it.
Brad
Makefile
