Re: [Fink-users] clang issues
On 3/30/14, 8:29 pm, Alexander Hansen wrote: On 3/26/14, 10:10 AM, Alexander Hansen wrote: It might be a good idea to insert -Wno-error=unused-command-line-argument-hard-error-in-future for clang builds. This will let people with the Xcode 5.1 tools build packages while still noting the unused command line arguments so that we can find and fix them. If we want to go with this route, there are a couple of options: 1) Insert it in the *FLAGS variables by default 2) put it in the compiler wrapper Thoughts, preferences, etc? I've just done option 1) in the github master (9a6c39a2b8f4c47d6da8fd6cda1e5f23a72bd088) I tried to be conservative and not change anything for 10.7-, and/or Xcode 5.0- . I'd appreciate any feedback on this before it gets released. I think it's a good idea. I have no preference on which method--I'm still newbie enough with this that I don't know the relative pros and cons of each option--but doing something global seems to me to be more effective use of the package maintainers' time than waiting for each affected package to be reported with a clang error before it can be fixed and built. I'm sure that since March 10, you haven't had much chance to work on anything fink-related other than fixing affected packages. When you consider how infrequently some packages get installed, it may be months or even years before every affected package is identified. Unless Apple backpedals on the strictness of clang in this regard, this will surely be something we have to deal with for the indefinite foreseeable future. [ObBadJoke: Q: What is the sound of Apple breaking open source builds? A: CLANG! Okay, I said it was bad.] Mark D. McKean qpa...@quantumpanda.com -- ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] clang issues
On 3/31/14, 12:16 PM, Mark D. McKean wrote: On 3/30/14, 8:29 pm, Alexander Hansen wrote: On 3/26/14, 10:10 AM, Alexander Hansen wrote: It might be a good idea to insert -Wno-error=unused-command-line-argument-hard-error-in-future for clang builds. This will let people with the Xcode 5.1 tools build packages while still noting the unused command line arguments so that we can find and fix them. If we want to go with this route, there are a couple of options: 1) Insert it in the *FLAGS variables by default 2) put it in the compiler wrapper Thoughts, preferences, etc? I've just done option 1) in the github master (9a6c39a2b8f4c47d6da8fd6cda1e5f23a72bd088) I tried to be conservative and not change anything for 10.7-, and/or Xcode 5.0- . I'd appreciate any feedback on this before it gets released. I think it's a good idea. I have no preference on which method--I'm still newbie enough with this that I don't know the relative pros and cons of each option--but doing something global seems to me to be more effective use of the package maintainers' time than waiting for each affected package to be reported with a clang error before it can be fixed and built. I'm sure that since March 10, you haven't had much chance to work on anything fink-related other than fixing affected packages. When you consider how infrequently some packages get installed, it may be months or even years before every affected package is identified. Unless Apple backpedals on the strictness of clang in this regard, this will surely be something we have to deal with for the indefinite foreseeable future. [ObBadJoke: Q: What is the sound of Apple breaking open source builds? A: CLANG! Okay, I said it was bad.] Mark D. McKean qpa...@quantumpanda.com I just added the changes to the 0.36.branch. If you want to try the change out: 1) Download the zip file from https://github.com/fink/fink/tree/branch_0_36, 2) Unzip it 3) Run ./inject.pl from the unzipped source directory. That will install fink-0.36.3.1.git. Doing it this way rather than from git master allows updates to new releases in the 0.36.x series to be installed--master installs as fink-0.36.99.git right now. -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ -- ___ Fink-users mailing list Fink-users@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.macosx.fink.user Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Compilation of guile18 hangs
On 26/03/14 12:37, Chris Richardson wrote:
I’m having problems compiling guile18 (latest version, 1.8.8-6). Compilation
generates an error and then appears to hang. I’ve left it overnight in case
it’s doing something really slowly, but there doesn't appear to be any activity.
This is on a brand new 10.9.2 machine with the latest Xcode and command line
developer tools and a freshly installed, updated fink. It does the same thing
when max fink build jobs is set to 1.
Package manager version: 0.36.3.1
Distribution version: selfupdate-rsync Wed Mar 26 11:02:50 2014, 10.9, x86_64
Trees: local/main stable/main
Xcode.app: 5.1
Xcode command-line tools: 5.1.0.0.1.1393561416
Max. Fink build jobs: 8
---
[]
cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc
continuations.doc debug.doc deprecation.doc deprecated.doc discouraged.doc
dynl.doc dynwind.doc environments.doc eq.doc error.doc eval.doc evalext.doc
extensions.doc feature.doc fluids.doc fports.doc futures.doc gc.doc goops.doc
gsubr.doc gc-mark.doc gc-segment.doc gc-malloc.doc gc-card.doc guardians.doc
hash.doc hashtab.doc hooks.doc i18n.doc init.doc ioext.doc keywords.doc
lang.doc list.doc load.doc macros.doc mallocs.doc modules.doc numbers.doc
objects.doc objprop.doc options.doc pairs.doc ports.doc print.doc procprop.doc
procs.doc properties.doc random.doc rdelim.doc read.doc root.doc rw.doc
scmsigs.doc script.doc simpos.doc smob.doc sort.doc srcprop.doc stackchk.doc
stacks.doc stime.doc strings.doc srfi-4.doc srfi-13.doc srfi-14.doc
strorder.doc strports.doc struct.doc symbols.doc threads.doc throw.doc
values.doc variable.doc vectors.doc version.doc vports.doc weaks.doc ramap.doc
unif.doc dynl.doc filesys.
doc posix.doc net_db.doc socket.doc regex-posix.doc |
GUILE=/sw/src/fink.build/guile18-1.8.8-6/guile-1.8.8/build/pre-inst-guile
../../scripts/snarf-check-and-output-texi guile-procedures.texi || { rm
guile-procedures.texi; false; }
ERROR: Unbound variable: define
[Compilation hangs here]
I spent some time trying to chase this down, with partial success. What
I found:
This is a caused by another new feature of Apple's new clang. This
time, it is an improvement of the preprocessor that crashes the rather
horrible macro games the guile18 build system is playing.
In short, a preprocessor macro with an empty expansion now eats a
preceding newline, but guile18 (in its guile-snarf script) depends on
certain macro expansions starting a new line. This works with the
previous clang or also with gcc-fsf4.8 -E as a preprocessor, but not
with gcc -E from the new clang. The result is that libguile is
miscompiled and does not contain the symbol define (as well as a
couple dozen others).
It is not hard to patch for this problem, see the attached patch file.
The Unbound variable: define error then disappears.
Unfortunately, the build crashes still at the same place, which is the
first time in the build phase that the newly built guile executable is
used. This indicates that it or rather the libguile.dylib is still
miscompiled. This time, the error message is
ERROR: invalid arglist syntax: (hash paren_open SCM alist comma SCM key
paren_close)
Since this comes from the belly of a guile script
(snarf-check-and-output-texi, SCHEME!) and may involve some texinfo
thrown in, I am not sufficiently polyglot and have to give up at this point.
BTW, fink build guile20 crashes at the same place, with a segmentation
fault of the guile executable. I have a crash log if someone wants to
pursue this further.
--
Martin
--- guile-1.8.8/libguile/guile-snarf.in~2010-12-13 18:24:40.0
+0100
+++ guile-1.8.8/libguile/guile-snarf.in 2014-03-31 23:11:19.0 +0200
@@ -53 +53 @@
-${cpp} -DSCM_MAGIC_SNARF_INITS -DSCM_MAGIC_SNARFER $@ ${temp}
cpp_ok_p=true
+${cpp} -DSCM_MAGIC_SNARF_INITS -DSCM_MAGIC_SNARFER $@ | sed -e
's|XXX|\n|g' ${temp} cpp_ok_p=true
--- guile-1.8.8/libguile/snarf.h~ 2010-12-13 18:24:40.0 +0100
+++ guile-1.8.8/libguile/snarf.h2014-03-31 20:55:20.0 +0200
@@ -54 +54 @@
-# define SCM_SNARF_INIT(X) ^^ X ^:^
+# define SCM_SNARF_INIT(X) XXX^^ X ^:^
@@ -61 +61 @@
-^^ { \
+XXX^^ { \
@@ -275 +275 @@
-#define SCM_ASSERT(_cond, _arg, _pos, _subr) ^^ argpos _arg _pos __LINE__ ^^
+#define SCM_ASSERT(_cond, _arg, _pos, _subr) XXX^^ argpos _arg _pos __LINE__ ^^
--
___
Fink-users mailing list
Fink-users@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.macosx.fink.user
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-users
Re: [Fink-users] Compilation of guile18 hangs
Martin,
Thanks for the report. I don't have 10.8/9 to test, only 10.7.
Something looks odd in your patch, the redirection -- I would expect it to
look like:
${cpp} ... | sed ... ${temp}
instead of:
${cpp} ... | sed ... ${temp}
Can you confirm what you tried (guile18)?
When you tried guile, which %v-%r did you happen to try?
One or two revisions back, I fixed a segfault at the same time, but it may
have been related to the libgc (garbage collector). Can you tell me what
version of libgc you built with?
Fang
On 26/03/14 12:37, Chris Richardson wrote:
I?m having problems compiling guile18 (latest version, 1.8.8-6).
Compilation generates an error and then appears to hang. I?ve left it
overnight in case it?s doing something really slowly, but there doesn't
appear to be any activity.
This is on a brand new 10.9.2 machine with the latest Xcode and command
line developer tools and a freshly installed, updated fink. It does the
same thing when max fink build jobs is set to 1.
Package manager version: 0.36.3.1
Distribution version: selfupdate-rsync Wed Mar 26 11:02:50 2014, 10.9,
x86_64
Trees: local/main stable/main
Xcode.app: 5.1
Xcode command-line tools: 5.1.0.0.1.1393561416
Max. Fink build jobs: 8
---
[]
cat alist.doc arbiters.doc async.doc backtrace.doc boolean.doc chars.doc
continuations.doc debug.doc deprecation.doc deprecated.doc discouraged.doc
dynl.doc dynwind.doc environments.doc eq.doc error.doc eval.doc
evalext.doc extensions.doc feature.doc fluids.doc fports.doc futures.doc
gc.doc goops.doc gsubr.doc gc-mark.doc gc-segment.doc gc-malloc.doc
gc-card.doc guardians.doc hash.doc hashtab.doc hooks.doc i18n.doc init.doc
ioext.doc keywords.doc lang.doc list.doc load.doc macros.doc mallocs.doc
modules.doc numbers.doc objects.doc objprop.doc options.doc pairs.doc
ports.doc print.doc procprop.doc procs.doc properties.doc random.doc
rdelim.doc read.doc root.doc rw.doc scmsigs.doc script.doc simpos.doc
smob.doc sort.doc srcprop.doc stackchk.doc stacks.doc stime.doc
strings.doc srfi-4.doc srfi-13.doc srfi-14.doc strorder.doc strports.doc
struct.doc symbols.doc threads.doc throw.doc values.doc variable.doc
vectors.doc version.doc vports.doc weaks.doc ramap.doc unif.doc dynl.doc
filesys
.
doc posix.doc net_db.doc socket.doc regex-posix.doc |
GUILE=/sw/src/fink.build/guile18-1.8.8-6/guile-1.8.8/build/pre-inst-guile
../../scripts/snarf-check-and-output-texi guile-procedures.texi ||
{ rm guile-procedures.texi; false; }
ERROR: Unbound variable: define
[Compilation hangs here]
I spent some time trying to chase this down, with partial success. What I
found:
This is a caused by another new feature of Apple's new clang. This time, it
is an improvement of the preprocessor that crashes the rather horrible
macro games the guile18 build system is playing.
In short, a preprocessor macro with an empty expansion now eats a preceding
newline, but guile18 (in its guile-snarf script) depends on certain macro
expansions starting a new line. This works with the previous clang or also
with gcc-fsf4.8 -E as a preprocessor, but not with gcc -E from the new
clang. The result is that libguile is miscompiled and does not contain the
symbol define (as well as a couple dozen others).
It is not hard to patch for this problem, see the attached patch file.
The Unbound variable: define error then disappears.
Unfortunately, the build crashes still at the same place, which is the first
time in the build phase that the newly built guile executable is used. This
indicates that it or rather the libguile.dylib is still miscompiled. This
time, the error message is
ERROR: invalid arglist syntax: (hash paren_open SCM alist comma SCM key
paren_close)
Since this comes from the belly of a guile script
(snarf-check-and-output-texi, SCHEME!) and may involve some texinfo thrown
in, I am not sufficiently polyglot and have to give up at this point.
BTW, fink build guile20 crashes at the same place, with a segmentation fault
of the guile executable. I have a crash log if someone wants to pursue this
further.
--
David Fang
http://www.csl.cornell.edu/~fang/
--
___
Fink-users mailing list
Fink-users@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.macosx.fink.user
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-users
