libgomp/fortran test questions.

[IainS]

Some more information (darwin8 142487; darwin9 142477)

1/ most, if not all, shared runtime libraries (including libgfortran  
and libgomp) embed references to shared libgcc_s.1.dylib.
The nature of the embedded reference depends on the "--enable-version- 
specific-runtime-libs" option.

2/ The instruction
> ! { dg-options "  ...... -static-libgcc" { target *-*-darwin* } }

to use shared libgomp/libgfortran and static libgcc does two  
different things (on d8 vs. d9)

To print out the following: I embedded "-Wl,-t" after the "-shared- 
libgcc" in the dg-options.
-t causes the darwin ld command to print out the libraries used.

----

on darwin8:

set_ld_library_path_env_vars: ld_library_path=.:/Volumes/ScratchCS/ 
gcc-440-build/powerpc-apple-darwin8.11.0/./libgomp/.libs:/Volumes/ 
ScratchCS/gcc-440-build/gcc:/Volumes/ScratchCS/gcc-440-build/powerpc- 
apple-darwin8.11.0/./libgomp/../libgfortran/.libs
Testing libgomp.fortran/crayptr2.f90,  -O0
doing compile
pid is 25164 -25164
close result is 25164 exp9 0 1
output is /usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Pass 1
/usr/lib/crt1.o
/Volumes/ScratchCS/gcc-440-build/gcc/crt3.o
/Volumes/ScratchCS/gcc-440-build/powerpc-apple-darwin8.11.0/./ 
libgomp/.libs/libgomp.dylib
/var/tmp//cc89GAOG.o
/Volumes/ScratchCS/gcc-440-build/powerpc-apple-darwin8.11.0/./ 
libgomp/.libs/libgomp.dylib
/Volumes/ScratchCS/gcc-440-build/powerpc-apple-darwin8.11.0/./ 
libgomp/../libgfortran/.libs/libgfortran.dylib
/usr/lib/libm.dylib
/usr/lib/libSystem.dylib
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: warning can't open  
dynamic library: /Volumes/ScratchCS/gcc-440-install/lib/libgcc_s. 
1.dylib referenced from: /Volumes/ScratchCS/gcc-440-build/powerpc- 
apple-darwin8.11.0/./libgomp/.libs/libgomp.dylib (checking for  
undefined symbols may be affected) (No such file or directory, errno  
= 2)
/usr/lib/system/libmathCommon.A.dylib
/Volumes/ScratchCS/gcc-440-build/powerpc-apple-darwin8.11.0/./ 
libgomp/../libgfortran/.libs/libgfortranbegin.a(fmain.o)
/Volumes/ScratchCS/gcc-440-build/gcc/libgcc_eh.a(emutls.o)
/usr/libexec/gcc/powerpc-apple-darwin8/4.0.1/ld: Undefined symbols:
___udivdi3 referenced from libgomp expected to be defined in /Volumes/ 
ScratchCS/gcc-440-install/lib/libgcc_s.1.dylib
collect2: ld returned 1 exit status

====

The complaint is correct - the required shared library is not present  
(since the compiler is not installed) - however, perhaps the loader  
should let this pass since the library is not required until runtime.

If I manually install *just* the libgcc_s.1.dylib to its final  
position; the link completes - BUT the libgcc symbols are satisfied  
from the shared version and libgcc.a does not  get loaded.

I, honestly, don't really know if this correct behavior or not (we  
seem to be asking for two libgcc implementations in the same code).

===============================

on darwin9 the situation is more subtle.

Loading /Volumes/ScratchCS/gcc-4-4-trunk/libgomp/testsuite/lib/ 
libgomp-dg.exp
set_ld_library_path_env_vars: ld_library_path=.:/Volumes/ScratchCS/ 
gcc-440-build/i386-apple-darwin9.5.0/./libgomp/.libs:/Volumes/ 
ScratchCS/gcc-440-build/gcc:/Volumes/ScratchCS/gcc-440-build/i386- 
apple-darwin9.5.0/./libgomp/../libgfortran/.libs
Testing libgomp.fortran/crayptr2.f90,  -O0
doing compile
pid is 85706 -85706
output is /usr/lib/crt1.10.5.o
/Volumes/ScratchCS/gcc-440-build/i386-apple-darwin9.5.0/./ 
libgomp/.libs/libgomp.dylib
/var/folders/OW/OW-PGOtgHbKakssxFpJpkU++-0E/-Tmp-//ccf91qTk.o
/Volumes/ScratchCS/gcc-440-build/i386-apple-darwin9.5.0/ 
libgfortran/.libs/libgfortranbegin.a
/Volumes/ScratchCS/gcc-440-build/i386-apple-darwin9.5.0/ 
libgfortran/.libs/libgfortran.dylib
/usr/lib/libm.dylib
/Volumes/ScratchCS/gcc-440-build/gcc/libgcc_eh.a
/Volumes/ScratchCS/gcc-440-build/gcc/libgcc.a
/usr/lib/libSystem.dylib
/usr/lib/system/libmathCommon.A.dylib
/Volumes/ScratchCS/gcc-440-build/i386-apple-darwin9.5.0/ 
libgfortran/.libs/libgfortranbegin.a(fmain.o)
/Volumes/ScratchCS/gcc-440-build/gcc/libgcc_eh.a(emutls.o)

====

It does not complain about the missing library referenced by both  
libgfortran and libgomp -- I guess this is desirable behavior - since  
the libraries are not needed until run-time.

So the link completes.

However, the object still contains references to libgomp -> libgcc_s. 
1 which is not installed.

So when the object execute, this falls back to the system version  
(which happens to contain the required symbol).

Which means two *different* versions of libgcc are being used by the  
same code;
version old (system, used by libgomp/libgfortran) and version new  
(statically linked, used by the mainline).

---

Is this really the intention?

---


On 5 Dec 2008, at 20:38, IainS wrote:

> Hi,
>
> on darwin8 [10.4.11]
> .. and with the freshly built compiler uninstalled ..
> I get two sets of "make check" fails under libgomp.
>
> libgomp.fortran/crayptr2.f90 [for each torture case]
> libgomp.fortran/pr32550.f90 [for each torture case]
>
> both contain
> ! { dg-options "  ...... -static-libgcc" { target *-*-darwin* } }
>
> I am trying to track down what is happening (which is not  
> particularly transparent in the testsuite).
>
> It seems that:
> libgomp.1.dylib contains a reference to libgcc_s.1.dylib.
>
> and somehow (even with an apparently correct LD_LIBRARY_PATH) this  
> (possibly secondary?) reference to libgcc is not being satisfied.
>
> the compile line contains both -shared-libgcc and -static-libgcc  
> (but the static one is last - so I believe it should prevail).
>
> ---
>
> what is the intent of specifying both a dynamic linkage (implied by  
> libgomp.1.dylib) and a static linkage (-static-libgcc) ?
>
> ---
>
> the unresolved symbol (___udivdi3) *is* present in gcc/libgcc_s. 
> 10.4.dylib, gcc/libgcc_s.1.dylib and gcc/libgcc.a
>
> however, these are not being found - and this symbol is *not*  
> present in  /usr/lib/libgcc_s.1.dylib  -- which will be the fall- 
> back for dyld.
>
> ====
>
> I've used LD_TRACE_DYLIBS and LD_TRACE_ARCHIVES - and it would seem  
> that libgcc_eh.a is being loaded -- but NOT libgcc.a
>
>
> similarly, if I zap the { target *-*-darwin* }  from the testcase,  
> libgcc_s.10.4.dylib is loaded -- but NOT libgcc_s.1.dylib (which is  
> referenced by  libgcc_s.10.4.dylib)
>
> ====
>
> can anyone point me towards where I should be looking to debug this  
> further?
>
> on darwin9 it *appears* to work OK - but this might simply be  
> because the /usr/lib/libgcc_s.1.dylib contains the ___udivdi3  
> symbol anyway.
>
> ====
>
> I'm building/checking 142487 at the moment - so no more debugging  
> until tomorrow...
>
> Iain