As mentioned elsewhere, the UDI Reference Implementation is a non-trivial hunk of code that interfaces with deep, dark corners of a number of operating systems and a wide variety of host and add-in hardware. It also serves several potential audiences.

This page is a compendium of known issues and quirks that you may encounter when working with the reference implementation. If you are having trouble working with your copy of the reference implementation, check this page to see if the answer lies here.

If your problem doesn't appear here, check the bugs list for Project UDI to see if the problem has already been reported. If it has, you might want to supplement the problem report if you have additional useful information.

If your problem is does not appear in the buglist and is unique, you now have two choices:

1. Post a bug to the buglist describing your problem
2. Post a patch to the patch manager or patchlist describing the fix you found for the problem

General Issues

• Command line overrides on the make line are not applied
  
  Command lines overrides you have applied on the command line (e.g. "make CC=foo_cc") don't seem to be applied to the subsequent build operation.
  
  Solution: This is not a bug, it's a feature! Because there are no standards for things like Makefile content, compiler flags, linker flags, and required #defines for building kernel modules, UDI has specified the use of a standard build tool (udibuild)and a driver description file (the Static Properties file, usually udiprops.txt) which perform the necessary functions to build the driver. The source code dependencies are noted in the Static Properties (assuming this is a source code distribution) and the udibuild uses the information in this file to invoke the proper compile and link operations on your system.
  
  Because the udibuild tool usually knows what's best, it doesn't use any of the standard environment variables or command-line overrides. If you find yourself wanting to do this, think and then think again about why you need this; it might be that you are introducing environment dependencies into your otherwise portable UDI module.
  
  So, after all that thinking, you've determined that yes, you really need to provide overrides, and will we just get to the point here! The best way to find out what command line overrides apply is to get the tool to tell you about them. For the tools supplied with the reference implementation, invoking them with the -h flag (e.g. "udibuild -h") should cause them to output helpful usage information.
  
  In the example case we described above, you would probably determine that you wanted to set UDI_CC before invoking the make operation:
  
  # UDI_CC=foo_cc; export UDI_CC
# make

  or with the make operation:
  
  # make UDI_CC=foo_cc

  Caveat #1: Some things in the reference implementation are built directly from the Makefile without using udibuild. Therefore, you should also use the normal command line overrides as well (e.g. "make CC=foo_cc").
  
  Caveat #2: UDI specifies the presence of a udibuild utility, and the format and content of the Static Properties file for a UDI module. UDI does NOT specify the flags, environment overrides, or other utilization of the udibuild utility, other than to say that simply typing udibuild in the directory that contains the driver and the Static Properties file should be sufficient to build the module in most situations. This means that the overrides you use in one development environment may not apply in another development environment.
  
  

Linux Issues

• No support for 2.4 Kernels
  
  This is under development. Please feel free to contact us if you wish to contribute.
  
  
• "unterminated argument list for macro" when compiling
  
  More specifically, the error you are probably seeing is:
  
  envcommon/udi_mei.c:559:25: unterminated argument list for macro "_UDI_VA_ARGS_0"
udibuild: ERROR: `cc' command failed (1).
  
  This is due to an error in the Gnu C Compiler (gcc version 2.96). Unfortunately, this is the default compiler shipped with 2.4 kernels (e.g. RedHat 7.0).
  
  Solution: The solution is to use the kgcc compiler, which should already be present on the system. This can be done in a couple of ways:
  
  
  1. Create a link to the proper compiler early in the execution path. For example:
     
     # ln -s `which kgcc` /usr/local/bin/cc
# chmod +x /usr/local/bin/cc
# PATH=/usr/local/bin:$PATH

     
  2. Override the default compiler for the UDI build operation:
     
     # CC=kgcc; export CC
# UDI_CC=kgcc; export CC

     
  
  
  
• GDB hangs when stepping through Posix tests
  
  If GDB hangs after threads are created during the posix_init operations, you have a version of GDB that doesn't support Linux threads very well (e.g. the GDB shipped with RH7.0).
  
  Solution: Get a current version of GDB and build it locally for your system.
  
  

File last modified: 00:00 Thu January 1, 1970