Bug 21983

	When generating an executable, gcc 2.95.2 as shipped with FreeBSD
	4.1 links against libgcc, which includes important helper functions
	like __fixunsdfdi. For shared libraries, this does not happen.

	In some cases, like the example included below or the Wine port,
	shared libraries will have unresolved references to libgcc symbols.

	If such a library is linked against an executable, the unresolved
	libraries will be linked against the executable (sic!) and when
	loading the library upon startup of the executable, the reference
	is resolved.

	If such a library is loaded during run-time (by means of dlopen()),
	the executable may lack these helper functions as these were neeeded
	for the executable itself and dlopen() will fail.

	This is a bug in the hacked version of gcc 2.95.2 shipped with
	FreeBSD 4.1, a version of gcc 2.95.2 from pristine sources does
	not have this bug.
 
	Thanks to Ulrich Weigand <weigand@immd1.informatik.uni-erlangen.de>
	for tracking down and analysing this.

Fix: 

Remove the patch against FSF GCC 2.95.2 that causes this change.

	Modify the GCC specs to link against libgcc_pic?
How-To-Repeat: 
	Execute the following commands

 	  gcc -shared -o test.so test.c
          gcc -o main main.c
	  ./main

	using the following two source files:

	test.c

	  unsigned long long test(double x)
	  {
	  #if 1
	    return (unsigned long long) x;
	  #else
	    return 0;
	  #endif
	  }

	main.c

	  #include <dlfcn.h>

	  unsigned long long (*test)(double x);

	  int main()
	  {
	    void *lib;

	    lib = dlopen("./test.so", RTLD_NOW);
	    if (!lib)
	    {
	      printf("dlopen: %s\n", dlerror());
	      exit(1);
	      }

	    test = dlsym(lib, "test");
	    if (!test)
	    {
	      printf("dlsym: %s\n", dlerror());
	      exit(1);
	    }

	    test(1.0);
	  }