[Bug 2075] New: undefined symbols in various libs/apps in Linux due to incorrect SharedLibFooReqs or other factors

[bugzilla-daemon at freedesktop.org]

Please do not reply to this email: if you want to comment on the bug, go to          
the URL shown below and enter yourcomments there.   
 
https://bugs.freedesktop.org/show_bug.cgi?id=2075        
   
           Summary: undefined symbols in various libs/apps in Linux due to
                    incorrect SharedLibFooReqs or other factors
           Product: xorg
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: trivial
          Priority: P2
         Component: App/other
        AssignedTo: xorg-bugzilla-noise at freedesktop.org
        ReportedBy: mharris at www.linux.org.uk
                CC: kem at freedesktop.org


Various parts of the full monolithic 'xc' tree do not link properly to all
of their shared library dependancies.  In many cases, these bugs go unnoticed
because they often do not cause any really visible runtime problems on Linux,
and I assume on other OS's as well.  In some cases however, they do cause
problems, and they end up getting fixed eventually.

The bigger problem however, as I see it anyway, is that there are currently
no automated tests ran to detect undefined symbols at _build_ time, and fail
the build or at least warn, but I would prefer it to hard fail so things
get fixed instead of ignored.

If the build process was slightly enhanced to detect undefined symbols on
whatever OS/arch/toolchain combinations that have options for detecting this,
such as gcc's "-Wundef" and GNU ld's '-Wl,-z,defs' options, and hard fail
the build, the remaining undefined symbol problems that are hiding, could be
fleshed out quickly during a day or so of the development cycle.  The Imake
(or autotool in the future) build process could be automated to test wether
the installed gcc and ld support these commandline options or not, and
automatically enable the flags if the gcc/ld support it.

The result, would be that on Linux at least, and possibly other OS's, bugs
associated with undefined symbols due to improper linking, would no longer
occur.  Since most of these issues end up not being noticed for quite some
time, it would permanently wipe out this class of bug more or less (on 
Linux at least).

I mentioned this to a few people in IRC recently, who felt the idea had
a lot of merit for future X.Org releases, and suggested I file it in
Xorg bugzilla, in case someone with some spare brain cycles was interested
in working the Imake/autotool test(s) and associated Imake config file
doctory et al. into CVS.

Here are the details:

gcc option to warn about undefined identifiers in #if directives is: -Wundef
ld option to warn about undefined symbols at link time:  -Wl,-z,defs

Here is a test (from Ulrich Drepper) that can be used to test if gcc/ld
supports the link time options:

cat > test.c <<-EOF
extern void bar(void);
void foo(void){bar();}
EOF

gcc -shared -fpic -o u.so u.c -Wl,-z,defs

If the above test *succeeds*, the option is not supported, and the gcc and ld
flags should not be modified.

If the above test fails, the option is supported, then "-Wl,-z,defs" should
be added to SharedLibraryLoadFlags, by changing:

#define SharedLibraryLoadFlags  -shared

to:

#define SharedLibraryLoadFlags  -shared -Wl,-z,defs

This option was added to gcc on 2001-03-17, and so should work with all
stable gcc releases released after that point.  Once it's implemented for
Linux, it shouldn't be hard for other OS/arch maintainers to test it on
their systems and if supported there too, to enable it for them as well.

This is a simple project that someone new to X development might want to
tackle as an easy way of digging into the Imake system.        
   
   
--         
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email       
   
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.