Re: Mac OS X Leopard and conftest.dSYM directories
On 12-Nov-07, at 1:39 PM, Ralf Wildenhues wrote: make check TESTSUITEFLAGS='-v -x -k libtool' I don't see any dSYM. Thanks! Peter
Re: Mac OS X Leopard and conftest.dSYM directories
Ralf Wildenhues wrote: * Peter O'Gorman wrote on Mon, Nov 12, 2007 at 06:44:36AM CET: On 11-Nov-07, at 8:41 AM, Ralf Wildenhues wrote: OK? Could somebody with Leopard access please test this by running make all check TESTSUITEFLAGS='-v -x' Looks like one or two spots were missed. Here is the log with this patch applied. http://pogma.com/misc/checklog.txt.bz2 Thanks. One instance was missed in Autoconf: _AC_SYS_LARGEFILE_MACRO_VALUE. The other failing test is due to Libtool. Would be good if you could rerun make check TESTSUITEFLAGS='-v -x -k libtool' after installing the fixed Libtool, to see if it eliminates all failures. Ok. Will do so tonight. Thank you for fixing this. Peter
Re: Mac OS X Leopard and conftest.dSYM directories
* Bob Friesenhahn wrote on Sun, Nov 11, 2007 at 07:19:26PM CET: On Sun, 11 Nov 2007, Peter O'Gorman wrote: It is okay with me. You sure that you want to proceed this way, rather than changing rm conftest* to rm -rf conftest.dSYM rm conftest* (because the only possible problem with the change is that people have dirs named conftestsomething in their sources, but this does seem unlikely). I think that it is wise to not make unnecessary assumptions and to use the safer approach, particularly since it is so easy to do so. Well, if there wee anybody who'd use `conftestsomething' in their sources, then: - either it wasn't a directory, then `rm conftest*' would have already killed it - or it was a directory, then `./configure' would have already output those bogus warnings. Because of that, I consider `rm -rf conftest*' safe in situations where we said `rm -f conftest*' before; only where Autoconf delimited removal to more specific patterns does it make sense to still do so. I have applied the Libtool patches. Cheers, and thanks, Ralf
Re: Mac OS X Leopard and conftest.dSYM directories
On 12-Nov-07, at 1:39 PM, Ralf Wildenhues wrote: make check TESTSUITEFLAGS='-v -x -k libtool' I don't see any dSYM. Thanks! Peter
Re: Mac OS X Leopard and conftest.dSYM directories
Proposed patch for Autoconf (adding Jeff to THANKS not shown).
We can thank Apple for needing one more fork per link test now. :-/
FWIW, I do think that, of the fortran.m4 changes, all but the first hunk
are not necessary, rather, the `rm -f ...' lines could probably be
removed completely. OTOH, they don't add forks, and likely Fortran
compilers generate other files that _AC_LINK_IFELSE don't catch yet.
No need to be suprt efficient here IMVHO.
OK? Could somebody with Leopard access please test this by running
make all check TESTSUITEFLAGS='-v -x'
with it and sending output bzip2'ed?
Cheers, and thanks,
Ralf
Avoid warnings about conftest.dSYM directories on Mac OS X Leopard.
* lib/autoconf/fortran.m4 (_AC_PROG_FC_V_OUTPUT)
(_AC_LANG_PROGRAM_C_, _AC_FC_MAIN, __AC_FC_NAME_MANGLING):
Remove conftest.dSYM directory.
* lib/autoconf/general.m4 (_AC_LINK_IFELSE, _AC_RUN_IFELSE):
* lib/autoconf/lang.m4 (AC_LINK_IFELSE): Likewise.
(_AC_COMPILER_OBJEXT_REJECT): Reject *.dSYM.
* THANKS: Update.
Report and analysis by Jeff Squyres and Peter O'Gorman.
diff --git a/lib/autoconf/fortran.m4 b/lib/autoconf/fortran.m4
index 0907e40..e1adaf1 100644
--- a/lib/autoconf/fortran.m4
+++ b/lib/autoconf/fortran.m4
@@ -553,7 +553,7 @@ ac_[]_AC_LANG_ABBREV[]_v_output=`eval $ac_link
AS_MESSAGE_LOG_FD1 21 | grep
AS_ECHO([$ac_[]_AC_LANG_ABBREV[]_v_output]) AS_MESSAGE_LOG_FD
_AC_LANG_PREFIX[]FLAGS=$ac_save_FFLAGS
-rm -f conftest*
+rm -rf conftest*
# On HP/UX there is a line like: LPATH is: /foo:/bar:/baz where
# /foo, /bar, and /baz are search directories for the Fortran linker.
@@ -823,7 +823,7 @@ AC_CACHE_CHECK([for dummy main to link with _AC_LANG
libraries],
fi
AC_LANG_POP(C)dnl
ac_cv_[]_AC_LANG_ABBREV[]_dummy_main=$ac_cv_fortran_dummy_main
- rm -f conftest*
+ rm -rf conftest*
LIBS=$ac_[]_AC_LANG_ABBREV[]_dm_save_LIBS
])
[]_AC_FC[]_DUMMY_MAIN=$ac_cv_[]_AC_LANG_ABBREV[]_dummy_main
@@ -892,7 +892,7 @@ AC_CACHE_CHECK([for alternate main to link with _AC_LANG
libraries],
done
AC_LANG_POP(C)dnl
ac_cv_[]_AC_LANG_ABBREV[]_main=$ac_cv_fortran_main
- rm -f conftest*
+ rm -rf conftest*
LIBS=$ac_[]_AC_LANG_ABBREV[]_m_save_LIBS
])
AC_DEFINE_UNQUOTED([]_AC_FC[]_MAIN, $ac_cv_[]_AC_LANG_ABBREV[]_main,
@@ -1004,7 +1004,7 @@ AC_CACHE_CHECK([for _AC_LANG name-mangling scheme],
fi
LIBS=$ac_save_LIBS
- rm -f cfortran_test* conftest*],
+ rm -rf cfortran_test* conftest*],
[AC_MSG_FAILURE([cannot compile a simple Fortran program])])
])
])# __AC_FC_NAME_MANGLING
diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4
index 2834e25..69b4371 100644
--- a/lib/autoconf/general.m4
+++ b/lib/autoconf/general.m4
@@ -2493,6 +2493,7 @@ AS_IF([_AC_DO_STDERR($ac_link) {
dnl Delete also the IPA/IPO (Inter Procedural Analysis/Optimization)
dnl information created by the PGI compiler (conftest_ipa8_conftest.oo),
dnl as it would interfere with the next link command.
+rm -rf conftest.dSYM
rm -f core conftest.err conftest.$ac_objext conftest_ipa8_conftest.oo \
conftest$ac_exeext m4_ifval([$1], [conftest.$ac_ext])[]dnl
])# _AC_LINK_IFELSE
@@ -2548,6 +2549,7 @@ _AC_MSG_LOG_CONFTEST
m4_ifvaln([$3],
[( exit $ac_status )
$3])dnl])[]dnl
+rm -rf conftest.dSYM
rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext
conftest.$ac_objext m4_ifval([$1],
[conftest.$ac_ext])[]dnl
])# _AC_RUN_IFELSE
diff --git a/lib/autoconf/lang.m4 b/lib/autoconf/lang.m4
index b659b9f..9a82d57 100644
--- a/lib/autoconf/lang.m4
+++ b/lib/autoconf/lang.m4
@@ -401,6 +401,9 @@ m4_divert_pop()dnl
#
# - *.map, *.inf
# Created by the Green Hills compiler.
+#
+# - *.dSYM
+# Directory created on Mac OS X Leopard.
# _AC_COMPILER_OBJEXT_REJECT
@@ -408,7 +411,7 @@ m4_divert_pop()dnl
# Case/esac pattern matching the files to be ignored when looking for
# compiled object files.
m4_define([_AC_COMPILER_OBJEXT_REJECT],
-[*.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map |
*.inf])
+[*.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map |
*.inf | *.dSYM])
# _AC_COMPILER_EXEEXT_REJECT
Re: Mac OS X Leopard and conftest.dSYM directories
* Peter O'Gorman wrote on Sat, Nov 10, 2007 at 10:08:13PM CET: Ralf Wildenhues wrote: What about separated compilation and linking? Do the directories get created upon cc -g -c foo.c cc -g -o foo foo.o No, only when output is created directly from a source file (or when the user runs dsymutil). The compiler calls dsymutil in the case where it is going to delete the temporary object file (and with it the debugging information). say, these four examples: cc -g -o objsub/bar.o src/sub/foo.c (there was a '-c' missing here) cc -g -o bin/foo sub/baz.o ar cru sub/libfoo.a sub2/bar.o sub3/baz.o cc [shlib_options] -o sub/foo.dylib bar/obj.o In these cases the foo.dSYM directory structure is not created, out of curiosity, I tried: cc -g -o objsub/foo src/sub/foo.c and foo.dSYM was created in the output dir (objsub/foo.dSYM). OK. The barf that is output during configure is mostly harmless, but is annoying. We just need to change the tests that do compilation without any intermediate objects to either use intermediate objects, or rm -rf conftest.* afterwards. What happens if there is a conftest.dSYM file or directory lying around from an earlier test. Does that impact the test, so that we would also need to remove the directory beforehand? Thanks, Ralf
Re: Mac OS X Leopard and conftest.dSYM directories
[ http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/5811/focus=5817 ] AFAICS Automake needs no changes. Proposed patches for Libtool HEAD and branch-1-5. OK? Cheers, Ralf 2007-11-11 Ralf Wildenhues [EMAIL PROTECTED] Avoid warnings about conftest.dSYM directories on Mac OS X Leopard. * libltdl/m4/libtool.m4 (_LT_LINKER_BOILERPLATE) (_LT_LINKER_OPTION, _LT_CMD_GLOBAL_SYMBOLS): Remove conftest.dSYM directory. Report and analysis by Jeff Squyres and Peter O'Gorman. Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.120 diff -u -r1.120 libtool.m4 --- libltdl/m4/libtool.m4 12 Oct 2007 20:54:44 - 1.120 +++ libltdl/m4/libtool.m4 11 Nov 2007 17:48:47 - @@ -870,7 +870,7 @@ echo $lt_simple_link_test_code conftest.$ac_ext eval $ac_link 21 /dev/null | $SED '/^$/d; /^ *+/d' conftest.err _lt_linker_boilerplate=`cat conftest.err` -$RM conftest* +$RM -r conftest* ])# _LT_LINKER_BOILERPLATE @@ -1338,7 +1338,7 @@ $2=yes fi fi - $RM conftest* + $RM -r conftest* LDFLAGS=$save_LDFLAGS ]) @@ -3355,7 +3355,7 @@ echo $progname: failed program was: AS_MESSAGE_LOG_FD cat conftest.$ac_ext 5 fi - rm -f conftest* conftst* + rm -rf conftest* conftst* # Do not use the global_symbol_pipe unless it works. if test $pipe_works = yes; then 2007-11-11 Ralf Wildenhues [EMAIL PROTECTED] Avoid warnings about conftest.dSYM directories on Mac OS X Leopard. * libtool.m4 (_LT_LINKER_BOILERPLATE, AC_LIBTOOL_LINKER_OPTION) (AC_LIBTOOL_SYS_GLOBAL_SYMBOL_PIPE): Remove conftest.dSYM directory. Report and analysis by Jeff Squyres and Peter O'Gorman. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.188 diff -u -r1.314.2.188 libtool.m4 --- libtool.m4 11 Oct 2007 17:25:06 - 1.314.2.188 +++ libtool.m4 11 Nov 2007 17:50:04 - @@ -276,7 +276,7 @@ echo $lt_simple_link_test_code conftest.$ac_ext eval $ac_link 21 /dev/null | $SED '/^$/d; /^ *+/d' conftest.err _lt_linker_boilerplate=`cat conftest.err` -$rm conftest* +$rm -r conftest* ])# _LT_LINKER_BOILERPLATE @@ -700,7 +700,7 @@ $2=yes fi fi - $rm conftest* + $rm -r conftest* LDFLAGS=$save_LDFLAGS ]) @@ -4910,7 +4910,7 @@ echo $progname: failed program was: AS_MESSAGE_LOG_FD cat conftest.$ac_ext 5 fi - rm -f conftest* conftst* + rm -rf conftest* conftst* # Do not use the global_symbol_pipe unless it works. if test $pipe_works = yes; then
Re: Mac OS X Leopard and conftest.dSYM directories
Ralf Wildenhues wrote: [ http://thread.gmane.org/gmane.comp.sysutils.autoconf.bugs/5811/focus=5817 ] AFAICS Automake needs no changes. Proposed patches for Libtool HEAD and branch-1-5. OK? It is okay with me. You sure that you want to proceed this way, rather than changing rm conftest* to rm -rf conftest.dSYM rm conftest* (because the only possible problem with the change is that people have dirs named conftestsomething in their sources, but this does seem unlikely). So, okay to apply, assuming you think it safe :-) Thank you for working on this. Peter
Re: Mac OS X Leopard and conftest.dSYM directories
On Sun, 11 Nov 2007, Peter O'Gorman wrote: It is okay with me. You sure that you want to proceed this way, rather than changing rm conftest* to rm -rf conftest.dSYM rm conftest* (because the only possible problem with the change is that people have dirs named conftestsomething in their sources, but this does seem unlikely). I think that it is wise to not make unnecessary assumptions and to use the safer approach, particularly since it is so easy to do so. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: Mac OS X Leopard and conftest.dSYM directories
On 11-Nov-07, at 8:41 AM, Ralf Wildenhues wrote: Proposed patch for Autoconf (adding Jeff to THANKS not shown). We can thank Apple for needing one more fork per link test now. :-/ FWIW, I do think that, of the fortran.m4 changes, all but the first hunk are not necessary, rather, the `rm -f ...' lines could probably be removed completely. OTOH, they don't add forks, and likely Fortran compilers generate other files that _AC_LINK_IFELSE don't catch yet. No need to be suprt efficient here IMVHO. OK? Could somebody with Leopard access please test this by running make all check TESTSUITEFLAGS='-v -x' Looks like one or two spots were missed. Here is the log with this patch applied. http://pogma.com/misc/checklog.txt.bz2 Peter
Re: Mac OS X Leopard and conftest.dSYM directories
Jeff Squyres wrote: Ralf -- thanks for reporting this; I had a hectic week and could not get to this issue before now. We noticed this issue in the context of the Open MPI project (my laptop is a MacBook, just recently upgraded to Leopard). Note that I am *not* an OS X expert! Here's the smallest configure.ac in which I was able to make it happen: Yeah, I complained about it at WWDC a couple of times, was told configure is just giving a warning, nothing to worry about. Could not bring it up on a list due to NDA. When you do cc -o foo foo.c, because temporary object files are deleted, and DWARF stores its debugging information in the temporary object files, Apple's gcc runs the 'dsymutil' command before deleting the object file to create a file that will hold the application debugging information. Unfortunately, they chose to use, not a file, but a bundle directory structure. (I complained about this also). Autoconf will probably have to do rm -rf conftest* instead of rm conftest*. I don't know how many places this is required. If Jeff wants to workaround -gstabs, or no -g in CFLAGS should fix it. I have a bug for libtool that I need to fix too (libtool unpacks convenience libraries and uses the objects to create shared libraries, then deletes the objects, so the debugger can not find debugging information for that shared library - libtool deleted it). Hope this helps, Peter
Re: Mac OS X Leopard and conftest.dSYM directories
Peter O'Gorman wrote: Jeff Squyres wrote: Ralf -- thanks for reporting this; I had a hectic week and could not get to this issue before now. We noticed this issue in the context of the Open MPI project (my laptop is a MacBook, just recently upgraded to Leopard). Note that I am *not* an OS X expert! Here's the smallest configure.ac in which I was able to make it happen: Yeah, I complained about it at WWDC a couple of times, was told configure is just giving a warning, nothing to worry about. Could not bring it up on a list due to NDA. When you do cc -o foo foo.c, Of course, I meant: cc -o foo -g foo.c Peter
Re: Mac OS X Leopard and conftest.dSYM directories
Ralf -- thanks for reporting this; I had a hectic week and could not
get to this issue before now. We noticed this issue in the context of
the Open MPI project (my laptop is a MacBook, just recently upgraded
to Leopard). Note that I am *not* an OS X expert!
Here's the smallest configure.ac in which I was able to make it happen:
-
AC_INIT([leopard-.dsym-test], [1.0])
AC_PROG_CC
AC_TRY_LINK([], [])
-
If you run it, you'll see a conftest.dSYM left over when configure is
done. Dissecting this a little more, it appears that passing -g and
any flavor of -O (even -O0) to the Leopard built-in gcc will result in
one of these .dSYM directories:
# Just to be sure...
$ rm -rf *.dSYM
$ cat mytest.c EOF
int main() { return 0; }
EOF
$ gcc -g -O mytest.c
$ ls -ld *.dSYM
a.out.dSYM
Hope this helps!
On Nov 10, 2007, at 6:37 AM, Ralf Wildenhues wrote:
Hello there,
Jeff Squyres reported that on Mac OS X Leopard, some configure tests
create spurious warnings of the form:
rm: conftest.dSYM: is a directory
It seems either the compiler or the linker, or both, create these
directories and do not remove them again. I do not know the details,
for example whether compiler flags are needed to provoke this, and do
not have access to this system. Some Libtool and some Autoconf tests
are affected. Just searching the net for the warning reveals issues.
I remember that, in the past, when we made the removal patterns more
generous, we hit issues with third party macros that tried to inspect
generated file after/in the test, which makes me reluctant to suggest
to blindly change `rm -f conftest*' to `rm -rf conftest*' everywhere.
Further, I fail to find useful information about *.dSYM directories on
developer.apple.com, all I can see talks about files named that way.
Any chance somebody could help here? For example, if you have a
Leopard
system, it would help to see verbose output of git Autoconf's
testsuite,
to be able to find out which Autoconf macros are affected:
make check TESTSUITEFLAGS='-v -x'
(both stdout and stderr). This is going to be quite large, so please
pack it with bzip2 or so.
Cheers, and thanks,
Ralf
--
Jeff Squyres
Cisco Systems
Re: Mac OS X Leopard and conftest.dSYM directories
Hello Peter, Jeff, Thanks for your additional information; and thanks, Peter, for trying to work against this, umm, a bit ugly situation. * Peter O'Gorman wrote on Sat, Nov 10, 2007 at 04:01:09PM CET: Peter O'Gorman wrote: When you do cc -o foo foo.c, Of course, I meant: cc -o foo -g foo.c What about separated compilation and linking? Do the directories get created upon cc -g -c foo.c or cc -g -o foo foo.o and if they are created upon the former, are they needed for the latter? In which directory do they live with, and what names do they have with, say, these four examples: cc -g -o objsub/bar.o src/sub/foo.c cc -g -o bin/foo sub/baz.o ar cru sub/libfoo.a sub2/bar.o sub3/baz.o cc [shlib_options] -o sub/foo.dylib bar/obj.o Asking because there may be more changes needed for Automake and Libtool. Cheers, Ralf
Re: Mac OS X Leopard and conftest.dSYM directories
Ralf Wildenhues wrote: Hello Peter, Jeff, Thanks for your additional information; and thanks, Peter, for trying to work against this, umm, a bit ugly situation. * Peter O'Gorman wrote on Sat, Nov 10, 2007 at 04:01:09PM CET: Peter O'Gorman wrote: When you do cc -o foo foo.c, Of course, I meant: cc -o foo -g foo.c What about separated compilation and linking? Do the directories get created upon cc -g -c foo.c cc -g -o foo foo.o No, only when output is created directly from a source file (or when the user runs dsymutil). The compiler calls dsymutil in the case where it is going to delete the temporary object file (and with it the debugging information). say, these four examples: cc -g -o objsub/bar.o src/sub/foo.c cc -g -o bin/foo sub/baz.o ar cru sub/libfoo.a sub2/bar.o sub3/baz.o cc [shlib_options] -o sub/foo.dylib bar/obj.o In these cases the foo.dSYM directory structure is not created, out of curiosity, I tried: cc -g -o objsub/foo src/sub/foo.c and foo.dSYM was created in the output dir (objsub/foo.dSYM). The barf that is output during configure is mostly harmless, but is annoying. We just need to change the tests that do compilation without any intermediate objects to either use intermediate objects, or rm -rf conftest.* afterwards. Peter
