Since the Dynamic Library Builder does not support generic classes, a
line in the shared library definition file that names a generic class should
probably be ignored, rather than crashing the compiler.

The bug seems to be in {E_DYNAMIC_LIB}.add_export_feature_from_file
(or in called routine `add_export_feature', depending on where you want to
fix it).

The svn diff for one proposed fix is (with lines shifted left for
readability):

--- /home/eiffel/svn/trunk/Src/Eiffel/API/interface/e_dynamic_lib.e     (revision 86670)
+++ /home/eiffel/svn/trunk/Src/Eiffel/API/interface/e_dynamic_lib.e     (working copy)
@@ -201,7 +201,7 @@

      if class_i /= Void then
              dl_class := class_i.compiled_class
-             if not dl_class.is_precompiled then
+             if not dl_class.is_precompiled and dl_class.actual_type.has_associated_class_type (Void) then
                  api_feature_table:= dl_class.api_feature_table
                  if api_feature_table.has_key (t_routine) then
                          dl_routine:= api_feature_table.found_item


This prevents adding a dynamic export feature for TEST if TEST is a generic
class.  If a dynamic export feature is added anyway (which is what the current
code does), the precondition of {GEN_TYPE_A}.has_associated_class_type is
violated when called with context Void.

I'm not very familiar with the compiler yet, so the proposed fix may be
incorrect.