[testsuite] Don't explicitly link libgomp tests with -lgomp (PR target/49541)

As described in the PR, the fact that the libgomp testsuite always links
with -lgomp, even with -fno-openmp, causes testsuite failures on targets
(like Solaris) that need special options when linking libgomp.  With
-fgomp, this is taken care of by the relevant specs (like adding
-pthread), but not so otherwise.

I found no reason for that explicit -lgomp since this is already dealt
with by -fopenmp.

The following patch fixes the failures on Solaris 8 and was tested with
make check in libgomp on sparc-sun-solaris2.8, i386-pc-solaris2.10, and
x86_64-unknown-linux-gnu.

Ok for mainline and 4.6 branch?

	Rainer


2011-07-15  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	PR target/49541
	* testsuite/lib/libgomp.exp (libgomp_init): Don't add -lgomp to
	ldflags.

On Mon, Jul 18, 2011 at 01:53:40PM +0200, Rainer Orth wrote:
> As described in the PR, the fact that the libgomp testsuite always links
> with -lgomp, even with -fno-openmp, causes testsuite failures on targets
> (like Solaris) that need special options when linking libgomp.  With
> -fgomp, this is taken care of by the relevant specs (like adding
> -pthread), but not so otherwise.

Needing special options to link against -lgomp is unfortunate, -lgomp
is what users want to link against if they have an OpenMP program that calls
some of the omp_* functions unconditionally if they want to compile it
without OpenMP parallelization.  For -static I can understand why special
options are needed, but for dynamic linking it is weird.

> The following patch fixes the failures on Solaris 8 and was tested with
> make check in libgomp on sparc-sun-solaris2.8, i386-pc-solaris2.10, and
> x86_64-unknown-linux-gnu.
> 
> Ok for mainline and 4.6 branch?

In any case, -lgomp explicitly isn't needed in the testsuite, so this is ok
for trunk/4.6.

> 2011-07-15  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>
> 
> 	PR target/49541
> 	* testsuite/lib/libgomp.exp (libgomp_init): Don't add -lgomp to
> 	ldflags.

	Jakub

Jakub Jelinek <jakub@redhat.com> writes:

> On Mon, Jul 18, 2011 at 01:53:40PM +0200, Rainer Orth wrote:
>> As described in the PR, the fact that the libgomp testsuite always links
>> with -lgomp, even with -fno-openmp, causes testsuite failures on targets
>> (like Solaris) that need special options when linking libgomp.  With
>> -fgomp, this is taken care of by the relevant specs (like adding
>> -pthread), but not so otherwise.
>
> Needing special options to link against -lgomp is unfortunate, -lgomp
> is what users want to link against if they have an OpenMP program that calls
> some of the omp_* functions unconditionally if they want to compile it
> without OpenMP parallelization.  For -static I can understand why special
> options are needed, but for dynamic linking it is weird.

The case at hand is Solaris 8 TLS support, where e.g. __tls_get_addr
only lives in the alternate libthread.so in /usr/lib/lwp.  While
libgomp.so has the correct RPATH so ld.so.1 finds the right libthread
(i.e. not /usr/lib/libthread.so) at runtime, ld ignores RPATH and only
searches in its standard search patch and explicit -L args.  Without
-L/usr/lib/lwp, the link fails ;-(  Admittedly butt ugly.

>> The following patch fixes the failures on Solaris 8 and was tested with
>> make check in libgomp on sparc-sun-solaris2.8, i386-pc-solaris2.10, and
>> x86_64-unknown-linux-gnu.
>> 
>> Ok for mainline and 4.6 branch?
>
> In any case, -lgomp explicitly isn't needed in the testsuite, so this is ok
> for trunk/4.6.

Thanks.
        Rainer