Bug 24991

Created attachment 10321 [details]
gcc41-pr24991.patch

Does the attached patch cure it?

I applied the patch to what I had yesterday and did a make and install. I build a program with it but the program would not run. I got -

[dranta:~/sage/ibar/ibarOne] dir% rage20051111GF.x ibarOne.input
dyld: lazy symbol binding failed: Symbol not found: ___gthrw_pthread_mutex_lock
  Referenced from: /Users/dir/gfortran/lib/libgfortran.1.dylib
  Expected in: flat namespace

dyld: Symbol not found: ___gthrw_pthread_mutex_lock
  Referenced from: /Users/dir/gfortran/lib/libgfortran.1.dylib
  Expected in: flat namespace

Trace/BPT trap
[dranta:~/sage/ibar/ibarOne] dir% gfortran --v
Using built-in specs.
Target: powerpc-apple-darwin8.3.0
Configured with: ./configure --prefix=/Users/dir/gfortran --enable-languages=c,f95
Thread model: posix
gcc version 4.2.0 20051122 (experimental)

Can you configure with objc as well to see if you see similar problem
in libobjc?
In any case, preprocessed source (with -E -dD in place of -c) for
one of the files that include io.h (say environ.c) would be helpful.
This sounds like weakref attribute not working for you.

This is actually not a cross build, but a build with srcdir == builddir.

Nothing called gthrw_pthread_mutex_lock (Darwin only has pthread_mutex_lock)is in any of the libraries as a terminator. If I run gcc directly, I do not know how to get all the flags set correctly to get a meaningful preprocessed output from environ.c - is there some macro that will pick up all the required parameters for this configuration ? When I touched environ.c and did another make - I found some warning messages in the output about the thread routines. 

can't find atom for N_GSYM stabs compile_options:G(0,5)=(0,6)=s8warn_std:(0,4),0,32;allow_std:(0,4),32,32;; in .libs/compile_options.o
can't find atom for N_GSYM stabs options:G(0,25)=(0,26)=s80stdin_unit:(0,8),0,32;stdout_unit:(0,8),32,32;stderr_unit:(0,8),64,32;optional_plus:(0,8),96,32;allocate_init_flag:(0,8),128,32;allocate_init_value:(0,8),160,32;locus:(0,8),192,32;separator_len:(0,8),224,32;separator:(0,5),256,64;mem_check:(0,8),320,32;use_stderr:(0,8),352,32;all_unbuffered:(0,8),384,32;default_recl:(0,8),416,32;fpu_round:(0,8),448,32;fpu_precision:(0,8),480,32;fpe:(0,8),512,32;sighup:(0,8),544,32;sigint:(0,8),576,32;; in .libs/environ.o
can't find atom for N_GSYM stabs l8_to_l4_offset:G(0,2) in .libs/main.o
ld: warning weak symbol references not set in output with MACOSX_DEPLOYMENT_TARGET environment variable set to: 10.1
ld: warning weak referenced symbols:
_pthread_cancel
_pthread_mutex_lock
_pthread_mutex_trylock
_pthread_mutex_unlock
can't find atom for N_GSYM stabs max_offset:G(0,30) in .libs/unit.o
can't find atom for N_GSYM stabs unit_root:G(0,1) in .libs/unit.o
can't find atom for N_GSYM stabs unit_lock:G(0,35) in .libs/unit.o

Can you build from a clean directory?  It sounds like you are building in a non clean one which might cause these issues.

I did a complete rebuild with the same results  -

mkdir gfortran
cd gfortran
svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
cd gcc
patch -p0 < /Users/dir/Desktop/gcc41-pr24991.patch
configure --prefix=/Users/dir/gfortran --enable-languages=c,f95
make -j 4
make install




[dranta:~/sage/ibar/ibarOne] dir% rage20051111GF.x ibarOne.input
dyld: lazy symbol binding failed: Symbol not found: ___gthrw_pthread_mutex_lock
  Referenced from: /Users/dir/gfortran/lib/libgfortran.1.dylib
  Expected in: flat namespace

dyld: Symbol not found: ___gthrw_pthread_mutex_lock
  Referenced from: /Users/dir/gfortran/lib/libgfortran.1.dylib
  Expected in: flat namespace

Trace/BPT trap

I built a new version last week and it works fine -

[dranta:~/tests/gfortran-D] dir% gfortran --v
Using built-in specs.
Target: powerpc-apple-darwin8.3.0
Configured with: ./configure --prefix=/Users/dir/gfortran --enable-languages=c,f95
Thread model: posix
gcc version 4.1.0 20051114 (experimental)

touch libgfortran/runtime/environ.c
make all-target-libgfortran > LOG
then either cut'n'paste the line that compiled environ.c and replace -c with
-E -dD and -o ..../environ.o with -o /tmp/environ.i and run that command,
or do the same with sed or something similar and pipe it to shell.

__gthrw_* routines are recently introduced routines in gthr*.h, which either
have the new weakref attribute or through __asm () are redirected to the real
routines.

Created attachment 10329 [details]
The preprocessed output for environ.c

The preprocessed output for environ.c

That looks sane, using __weakref__ attribute and on powerpc64-linux -> powerpc-apple-darwin8.3.0 cross I verified it creates also reasonable assembly.

So, can you look through all object files that are linked into libgfortran.1.dylib and see with say nm which object actually references
___gthrw_* routines?

Created attachment 10330 [details]
nm of  the gfortran libraries

References to the "gthrw" routines seem to be everywhere.
(I am out of here till next Monday)

Before you leave, can you still preprocess say unit.c or unix.c the same
way you did it for environ.c?
Or, if it is too late, can anyone else with access to ppc darwin reproduce it?

I can try tomorrow.  To trigger this it's enough to do a in-srcdir c,fortran,objc build, right?

Paolo

Comment #7 seems to suggest that (even just --enable-languages=c,fortran).

Just to be sure, you should be building outside the gcc directory hierarchy. This is (a cleaned up version of the) script I use for doing a clean build:

#!/bin/sh

GCCDIR=trunk

cd $GCCDIR
contrib/gcc_update
cd ..
rm -rf objdir
mkdir objdir
cd objdir
../$GCCDIR/configure --enable-checking --prefix=$HOME/src/gfortran/install --enable-languages=fortran
make
make install
cd gcc
make check-fortran
cd ../..

# EOF

You see that the objdir where all the building is done, is entirely separate from the checked out gcc tree ("trunk" directory). As an added bonus, for a clean build you just blow away objdir, no need to check out gcc again.

Created attachment 10336 [details]
unit.i

Created attachment 10337 [details]
unit.s

From the files I got in private mail it seems that weakref attribute doesn't
work on darwin.  But I haven't managed to convince my powerpc64-linux
-> powerpc-apple-darwin8.3.0 cross to actually generate any
.indirect_symbol directives in the assembly and therefore I can't confirm
that myself (and thus can't debug it).
Do you see e.g. failures in gcc.dg/attr-weakref-1.c test as well?
Judging from http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg01154.html
the test fails and therefore I'd say this is not a gfortran bug,
you'll have identical problems in C++ or Objective-C.

(In reply to comment #18)

Jakub,
       I exactly the same failures here on gcc 4.1 branch for the gcc and g++ testsuite as are
reported at http://gcc.gnu.org/ml/gcc-testresults/2005-11/msg01154.html. Assuming that
weakref attribute doesn't work on Darwin, what exactly are our options for fixing this?
                             Jack

It needs to be fixed, gthr*.h relies on it.  __attribute__((weeakref)) is
supposed to work on all targets that support the weak attribute and darwin
is one of them, either through .weakref assembler directive (very recent binutils, for ELF and maybe *COFF?) or via GCC's internal support (for the
rest of the targets).
Best would be if Darwin maintainers or other people familiar with darwin.c
and/or Mach-O could work with Alexandre on resolving this (that's why I
have added them to CC).

Jakub,
     Shouldn't you add Geoffrey Keating to the cc for this bug as he does the cctools releases. FYI, I am using his last 590.12 cctools release (http://gcc.gnu.org/ml/gcc/2005-10/msg01218.html) with Xcode 2.2 installed over it.
                 Jack

One other note. I tried a build of gcc 4.1 branch with MACOSX_DEPLOYMENT_TARGET set to 10.4 as well since that causes libtool to use '-undefined dynamic_lookup' instead of '-undefined suppress' when linking shared libraries. That change didn't help at all. The libgfortran still shows...

nm libgfortran.1.0.0.dylib | grep gthrw_pthread_mutex
         U ___gthrw_pthread_mutex_lock
         U ___gthrw_pthread_mutex_trylock
         U ___gthrw_pthread_mutex_unlock

which are unresolved at link time.

Ok, the problem is that GTHREAD_USE_WEAK is not being defined to 0 as config/darwin.h defines it to 0.

This is not really a target issue fully and what libgfortran or gthr.h does is incorrect.  I wonder how libstdc++ works correctly but not libgfortran does.

Note libobjc is fine as it does:
#include "config.h"
#include "tconfig.h"
#include "coretypes.h"
#include "tm.h"
#include "defaults.h"


so it gets the correct define.  Now to figure out why libstdc++ works.

The reason why libstdc++ works is because there is a define in the config header for libstdc++ for GTHREAD_USE_WEAK  being defined as 0.  So this is a libgfortran failure only.

This effects more than Darwin, this also effects HPUX, openbsd, and cygwin.
./pa/pa64-hpux.h:#define GTHREAD_USE_WEAK 0
./pa/som.h:#define GTHREAD_USE_WEAK 0
./darwin.h:#define GTHREAD_USE_WEAK 0
./openbsd.h:#define GTHREAD_USE_WEAK 0

Andrew,
      Sorry if this is a stupid question, but how does this PR relate to the fact that...

gcc.dg/attr-weakref-1.c
gcc.dg/weak/weak-14.c

...fail on Darwin_8.3.0? Are they associated problems?
                     Jack

Some comments:

1. There is no need to use weak symbols for pthreads on Darwin.  There's no separate pthread library like on some other OSs.
2. Some older versions of Darwin do not support weak symbols *at all*.  Using a weak symbol in an executable will cause it not to load.
3. Unless you set the -mmacosx-version-min flag, the linker will not let you use weak symbols, it will make them strong.  If you really plan to not support earlier Darwin versions, though, it is better to set the flag, since that makes other efficiency improvements.
4. The 'weakref' attribute is new.  The gcc.dg/attr-weakref-1.c test fails on Darwin.  The feature appears to have been added very late in the 4.1 timeframe and so wouldn't necessarily have support on all targets, and bugs in it are not regressions and so are unlikely to be fixed for 4.1.  There's some work to do to make it properly integrate with the Darwin port, because Darwin already has weak_import and I believe these two attributes are actually the same thing.

So, I think it would be better if gfortran followed libstdc++ and didn't try to make the thread symbols weak on Darwin. Failing that, at least for 4.1, use weak_import rather than weakref on Darwin.

does this work for others too? Or do I miss a linux 'feature' ?

Index: io/io.h
===================================================================
--- io/io.h     (revision 107496)
+++ io/io.h     (working copy)
@@ -32,7 +32,8 @@
 
 #include <setjmp.h>
 #include "libgfortran.h"
-#ifdef HAVE_PRAGMA_WEAK
+#include "tm.h"
+#ifdef GTHREAD_USE_WEAK
 /* Used by gthr.h.  */
 #define SUPPORTS_WEAK 1
 #endif

Testing on sparc-solaris8 and darwin-ppc?

libgfortran shouldn't be using gcc private headers, libobjc is getting rid of
that dependency as well, see libobjc_noheaders branch.

Andreas,
      The undefined symbols under Darwin_8.3.0 occur as follows...

___gthrw_pthread_mutex_lock

rand.o
random.o
unix.o
unit.o

___gthrw_pthread_mutex_trylock

unix.o
unit.o

___gthrw_pthread_mutex_unlock

rand.o
random.o
unix.o
unit.o

FYI.

The patch in the Patch URL seems to resolve the symbol problems. I am seeing a failure in the fgetc_# and fputc_# gfortran tests now due to timeouts. However I saw those as well when I regressed out the changes from http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106704. So I believe that is a different bug than PR 24991.

FYI...here is what I get when I manually run fgetc_1 through gdb...

[Jack-Howarths-Computer:~/Desktop] howarth% gfortran -g -o fgetc_1 fgetc_1.f90
[Jack-Howarths-Computer:~/Desktop] howarth% gdb fgetc_1
GNU gdb 6.1-20040303 (Apple version gdb-434) (Wed Nov  2 17:28:16 GMT 2005)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "powerpc-apple-darwin"...Reading symbols for shared libraries .... done

(gdb) break fgetc_1.f90:4
Breakpoint 1 at 0x26e0: file fgetc_1.f90, line 4.
(gdb) r
Starting program: /Users/howarth/Desktop/fgetc_1 
Reading symbols for shared libraries .++ done

Breakpoint 1, MAIN__ () at fgetc_1.f90:6
6         s = "12345"
(gdb) s
Current language:  auto; currently fortran
*__gfortran_copy_string (destlen=5, dest=0xbffff298 "\217?\217?a???", srclen=5, src=0x2fbc "12345") at ../../../gcc-4.1-20051125/libgfortran/intrinsics/string_intrinsics.c:95
95            memmove (dest, src, srclen);
(gdb) s
Current language:  auto; currently c
88        if (srclen >= destlen)
(gdb) s
99      }
(gdb) s
*__gfortran_copy_string (destlen=5, dest=0xbffff298 "\217?\217?a???", srclen=5, src=0x2fbc "12345") at ../../../gcc-4.1-20051125/libgfortran/intrinsics/string_intrinsics.c:91
91            memmove (dest, src, destlen);
(gdb) s
99      }
(gdb) s
91            memmove (dest, src, destlen);
(gdb) s

...at which point the debugger never returns anything (matchin the hang of fgetc_1 I see outside of gdb).

Created attachment 10353 [details]
Pach that fixes the weakref behavior on darwin

Could someone with access to the affected OS please try this patch?  It seems to me that, with this patch, we generate correct code for weakrefs.

With patches "gcc41-pr24991.patch" (I also need this to build on LINUX) and "gcc-weakref-darwin.patch" (the patch gcc/ChangeLog  failed, but that did not matter) installed and a fresh down load of gfortran, gfortran builds and I have used the newly created gfortran to compile and run three of my programs -

   Thanks All.

Subject: Bug 24991

Author: aoliva
Date: Tue Nov 29 00:47:28 2005
New Revision: 107639

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107639
Log:
PR libfortran/24991
* config/darwin.c (machopic_indirection_name,
machopic_output_indirection): Follow transparent alias chain.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/darwin.c

Subject: Bug 24991

Author: aoliva
Date: Tue Nov 29 00:56:16 2005
New Revision: 107640

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107640
Log:
PR libfortran/24991
* config/darwin.c (machopic_indirection_name,
machopic_output_indirection): Follow transparent alias chain.

Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/config/darwin.c

Jakub, Alexandre, what's the status on this PR? If I read it correctly, it's fixed on darwin but still not fixed on hpux, is that right?

No, in tree builds are still broken everywhere, as
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01687.html
hasn't been approved yet.
All the other problems are fixed already.
I'm using that patch in my tree on many arches for quite some time, although
I'm never doing in tree builds myself.

Subject: Bug 24991

Author: jakub
Date: Fri Dec  9 13:50:11 2005
New Revision: 108280

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108280
Log:
	PR libfortran/24991
	* acinclude.m4: Include acx.m4 and no-executables.m4.
	* configure.ac: Add GCC_TOPLEVEL_SUBDIRS.
	* configure: Rebuilt.
	* Makefile.am (AM_CPPFLAGS): Use $(host_subdir) in build dir
	path.
	* Makefile.in: Rebuilt.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/Makefile.am
    trunk/libgfortran/Makefile.in
    trunk/libgfortran/acinclude.m4
    trunk/libgfortran/configure
    trunk/libgfortran/configure.ac

Subject: Bug 24991

Author: jakub
Date: Tue Dec 13 08:18:54 2005
New Revision: 108469

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108469
Log:
	PR libfortran/24991
	* acinclude.m4: Include acx.m4 and no-executables.m4.
	* configure.ac: Add GCC_TOPLEVEL_SUBDIRS.
	* configure: Rebuilt.
	* Makefile.am (AM_CPPFLAGS): Use $(host_subdir) in build dir
	path.
	* Makefile.in: Rebuilt.

Modified:
    branches/gcc-4_1-branch/libgfortran/ChangeLog
    branches/gcc-4_1-branch/libgfortran/Makefile.am
    branches/gcc-4_1-branch/libgfortran/Makefile.in
    branches/gcc-4_1-branch/libgfortran/acinclude.m4
    branches/gcc-4_1-branch/libgfortran/configure
    branches/gcc-4_1-branch/libgfortran/configure.ac

Subject: Bug 24991

Author: jakub
Date: Tue Dec 13 08:31:41 2005
New Revision: 108471

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108471
Log:
	PR libfortran/24991
	* acinclude.m4 (LIBGFOR_CHECK_PRAGMA_WEAK): Rename to...
	(LIBGFOR_GTHREAD_WEAK): ... this.  Define SUPPORTS_WEAK rather
	than HAVE_PRAGMA_WEAK.  Define GTHREAD_USE_WEAK to 0 on hosts
	that shouldn't use weak in gthr.h.
	* configure.ac: Use LIBGFOR_GTHREAD_WEAK instead of
	LIBGFOR_CHECK_PRAGMA_WEAK.
	* config.h.in: Regenerated.
	* configure: Regenerated.
	* io/io.h (SUPPORTS_WEAK): Don't define here.

	* intrinsics/ftell.c (ftell, FTELL_SUB): Add unlock_unit call.
	* intrinsics/fget.c (fgetc, fputs): Likewise.
	* intrinsics/tty.c (ttynam): Likewise.

Modified:
    trunk/libgfortran/ChangeLog

Fixed in SVN.