it doesn't have to be mod_cache

and it doesn't have to be built with apxs

it just has to be built as a DSO with gcc, and it can reference
libgcc.a symbols that weren't included in httpd and/or weren't
exported by httpd


True 'nuff... I was simply trying to indicate a quick and dirty way to recreate the issue and show the dependency. If you do build mod_cache at the same time however, the libgcc dependency is "hidden" (it still exists and, in most cases, the required library mojo happens during the link phase so that it gets pulled in correctly at runtime).


a critical point in deciding how to address this is that it isn't just that line of code; maybe it is just that line of code with today's checkout of CVS with your current level of gcc and your configure options, but it is different line(s) of code for somebody else and their checkout and their gcc and their configure options

so changing that line of code is no solution except maybe as your own
local modification which you can maintain until your gcc or your
checkout or your compile/configure options change sufficiently to add
a dependency elsewhere; given that, how can that source code change be
checked into CVS?

Well... I've confirmed that with that change, we remove that libgcc dependency for the singular case of the code not requiring __floatdidf :)

Yes, I agree that the issue is deeper and that doing
these line-by-line hacks will likely be more
trouble than they are worth (eventually) but what
disturbed me (as mentioned) was the "yeah, so
what" attitude. Kind of defeats the whole purpose
of httpd being licensed the way it is, and
allowing companies like RedHat and Covalent and
IBM to redistribute it if the resulting code
results in dependencies that circumvent the
desire of LICENSE.

I'm not gung-ho about the patch; I am gung-ho
about the *reason* for the patch. ;)



Reply via email to