2009/8/22 Paul H. Hargrove <[email protected]>: > Alan Woodland wrote: >> >> 2009/8/22 Paul H. Hargrove <[email protected]>: >> >>> >>> Removing the check for _end will negate the validation that is being >>> performed. >>> Instead, I would suggest that an alternative symbol should be used for >>> validation. >>> >>> Does the build work after replacing ' [AB] _end' with ' [TD] sys_open' in >>> the line quoted from configure? >>> >> >> As far as I can make out patching configure as you suggested has the >> desired effect with no negative side effects. What I can't quite >> figure out still is why _end would disappear from Debian's 2.6.30 >> System.map. >> >> If you're ok with it I'll make an upload with this patch applied to >> configure tonight or tomorrow. >> >> Alan >> > > Alan, > > Keep in mind that configure is generated from configure.ac. If one were to > touch configure.in, any changes in configure would get lost. This makes the > use of the patched source "fragile". So, I suspect one wants to either: > 1) Patch ONLY configure.ac and regenerate configure > OR > 2) Patch both and "touch configure" to avoid an automatic re-run of autoconf > > I suspect #2 is the best/safest bet because it does not require the end-user > have autoconf. However, you should probably ask around to see if there is a > Debian standard for patches that affect files generated by autotools > (autoconf, automake, etc.). This can't be the first instance of something > like this.
After re-running autoconf the kernel module part fails to build, during configure with: configure: error: conditional "am__fastdepCXX" was never defined. Usually this means the macro was only invoked conditionally. make: *** [binary-modules] Error 1 configure was called with: ./configure --with-installed-libcr --with-installed-util --with-components=modules --prefix=/usr --with-linux=2.6.30-1-686 I think this comes from this line of configure.ac: # If building the tests, we can optionally test C++ if test x"$cr_build_tests" = xyes; then CR_PROG_CXX fi Calling CR_PROG_CXX unconditionally seems to prevent this problem, and I can't see any obvious negative repercussions for doing so... I knew there was a reason for not re-running autoconf! Alan -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
