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
[email protected]
List archive:
http://news.gmane.org/gmane.os.macosx.fink.user
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-users