| Summary: | undefined symbols in various libs/apps in Linux due to incorrect SharedLibFooReqs or other factors | ||
|---|---|---|---|
| Product: | xorg | Reporter: | Mike A. Harris <mharris> |
| Component: | App/other | Assignee: | Xorg Project Team <xorg-team> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | trivial | ||
| Priority: | high | CC: | kem |
| Version: | unspecified | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
On Darwin and Cygwin the *Lib.tmpl file describe correct libraries dependencies, since their respective linkers treat the described behaviour as an error. bsdLib.tmpl also has correct libraries dependencies too, because OpenBSD still has a few architectures whithout shared libs, and this also is an error on static libraries. Extra dependencies are described in each application's Imakefile when needed. Maybe these dependency lists should be put in a file used by all architectures. this is fixed in modular by way of: libfoo_la_LDFLAGS = -no-undefined not really interested in fixing this in monolith, so marking as fixed. please reopen if we want to target this at 6.9.1 as well. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.