[Libdlo] compile displaylink-mod-0.3 on kernel 2.6.32.2

[Luke Kenneth Casson Leighton]

On Sun, Dec 20, 2009 at 8:33 PM,  <libdlo-request at lists.freedesktop.org> wrote:
> Message: 1
> Date: Sun, 20 Dec 2009 14:33:09 -0600
> From: Kenneth Shotswell <shotswell21 at gmail.com>
> Subject: Re: [Libdlo] Libdlo Digest, Vol 8, Issue 11
> To: libdlo at lists.freedesktop.org
> Message-ID:
>        <2ea4fff70912201233t3ba85c07gf82212d7c9482cf2 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> When trying to compile displaylink-mod-0.3 on kernel 2.6.32.2 with UDLFB
> compiled into the kernel I get the following error message.... Sorry if this
> has been covered before :-)
>
> root at workstation:/home/shotsy# tar xzvf displaylink-mod-0.3.tar.gz
> [...]

> root at workstation:/home/shotsy/displaylink# make
> make -C /lib/modules/`uname -r`/build SUBDIRS=/home/shotsy/displaylink
> modules
> make[1]: Entering directory `/usr/src/linux-2.6.32.2'
>  CC [M]  /home/shotsy/displaylink/displaylink-main.o
>  CC [M]  /home/shotsy/displaylink/displaylink-usb.o
> /home/shotsy/displaylink/displaylink-usb.c: In function
> 'displaylink_edid_to_reg':
> /home/shotsy/displaylink/displaylink-usb.c:85: error: 'struct
> detailed_pixel_timing' has no member named 'hactive_hi'
> [... etc. etc.]

this looks suspiciously like the header files from the udlfb kernel
build that you've got installed already are being picked up as a
priority over-and-above the ones in the displaylink subdirectory of
the code you downloaded.

you can confirm this by enabling whatever debug mode it is that gets
the (stupid) kernel build process to hide the gcc command that builds
the actual .o file, unhide it, copy it, then replace "gcc -c" with
"gcc -E".  this will enable gcc "pre-processor" mode.  instead of
outputting an object file, it will output "pre-processed c code", with
all the #includes (and line numbers), all macros expanded (and line
numbers), everything.

you end up with a _really_ big file.

what you can then do is go through that output, looking for evidence
of #includes, looking for the definition of "struct
detailed_pixel_timing", and looking right next to that definition for
the file name and, conveniently, the exact line number of the file,
where that definition was pulled in from.

this is a simple straightforward process, and it's also _standard_
practice.  why exactly you're not entirely aware of standard debugging
processes for c programming when using gnu tools, i'm not entirely
sure, but there you go, that's what you can do to help yourself find
out what's going on.

i'll leave you to fill in the gaps about how to find out what the
kernel build process is trying to hide useful and important
information from you, etc.

once this is confirmed (or not), resolving how to change the order of
includes is the next line of business, which could be as simple as
changing the order in the Makefile - but... maybe not.

the priority is to find out what's going on, where that struct is
being pulled in from, etc. etc.  then further analysis can be carried
out

l.