With a new download of gfortran, the build now fails while building libgfortran with - make all-am /bin/sh ./libtool --mode=compile /Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc -B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/ -B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/bin/ -B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/lib/ -isystem /Users/dir/gfortran/powerpc-apple-darwin8.3.0/include -isystem /Users/dir/gfortran/powerpc-apple-darwin8.3.0/sys-include -DHAVE_CONFIG_H -I. -I../.././libgfortran -I. -iquote../.././libgfortran/io -I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config -I../../gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2 -c -o environ.lo `test -f 'runtime/environ.c' || echo '../.././libgfortran/'`runtime/environ.c /Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/xgcc -B/Users/dir/gfortran/gcc/host-powerpc-apple-darwin8.3.0/gcc/ -B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/bin/ -B/Users/dir/gfortran/powerpc-apple-darwin8.3.0/lib/ -isystem /Users/dir/gfortran/powerpc-apple-darwin8.3.0/include -isystem /Users/dir/gfortran/powerpc-apple-darwin8.3.0/sys-include -DHAVE_CONFIG_H -I. -I../.././libgfortran -I. -iquote../.././libgfortran/io -I../.././libgfortran/../gcc -I../.././libgfortran/../gcc/config -I../../gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -O2 -c ../.././libgfortran/runtime/environ.c -fno-common -DPIC -o .libs/environ.o In file included from ../.././libgfortran/runtime/../io/io.h:39, from ../.././libgfortran/runtime/environ.c:37: ../.././libgfortran/../gcc/gthr.h:114:26: error: gthr-default.h: No such file or directory In file included from ../.././libgfortran/runtime/environ.c:37: ../.././libgfortran/runtime/../io/io.h:465: error: expected specifier-qualifier-list before '__gthread_mutex_t' ../.././libgfortran/runtime/../io/io.h:660: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'unit_lock' ../.././libgfortran/runtime/../io/io.h:661: error: 'unit_lock' undeclared here (not in a function) ../.././libgfortran/runtime/../io/io.h:661: warning: type defaults to 'int' in declaration of 'unit_lock' ../.././libgfortran/runtime/../io/io.h: In function 'inc_waiting_locked': ../.././libgfortran/runtime/../io/io.h:836: error: 'gfc_unit' has no member named 'waiting' ../.././libgfortran/runtime/../io/io.h:836: error: incompatible type for argument 1 of '__sync_fetch_and_add' ../.././libgfortran/runtime/../io/io.h: In function 'predec_waiting_locked': ../.././libgfortran/runtime/../io/io.h:846: error: 'gfc_unit' has no member named 'waiting' ../.././libgfortran/runtime/../io/io.h:846: error: incompatible type for argument 1 of '__sync_add_and_fetch' ../.././libgfortran/runtime/../io/io.h: In function 'dec_waiting_unlocked': ../.././libgfortran/runtime/../io/io.h:856: error: 'gfc_unit' has no member named 'waiting' ../.././libgfortran/runtime/../io/io.h:856: error: incompatible type for argument 1 of '__sync_fetch_and_add' make[3]: *** [environ.lo] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libgfortran] Error 2 make: *** [all] Error 2
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.