Thanks. When I was looking at the Ruby site, I noticed that we were out
of date and was going to ask the owner about it. Based on your comments
below, I gather that you have picked up ownership. Correct?
-Norm
Amanda Waite wrote:
> I've looked at the webrev, understood it and it looks fine, even
> better now that it supports more than just one line continuation
> ('next if $2') as well as line continuations with empty strings.
>
> I also looked at the Ruby 1.8.7 p174 source which I'm shortly going to
> begin work on integrating and that doesn't contain this fix. I'll see
> if they have any plans to backport it.
>
> I also found other issues with the way Ruby is built (invalid
> configure options, protofix run twice). I'll raise bugs for them and
> either fix them with the update or make an intermediary fix.
>
> Thanks for finding this, sorry it caused you so much grief.
>
> Amanda
>
>
>
> Norm Jacobs wrote:
>> I have filed
>> 6883134 ruby build fails with proto path length of 40
>> to track this and have come up with a fix that someone more familiar
>> with ruby should look at. My webrev is at
>> http://cr.opensolaris.org/~jacobs/webrev-6883134/
>>
>> It appears that if strlen($ROOT) == 40 run into the problem, so
>> workspace pathname length of 22 on sparc and 23 on x86 seems to do it
>> for me. I took a look at mkconfig.rb and while it's largely greek to
>> me, It appears to use perl like regular expressions. The following
>> patch seems to fix it for me, but someone with ruby experience ought
>> to review this.
>>
>> --- ruby-1.8.7-p72/mkconfig.rb.orig Thu Sep 17 07:31:55 2009
>> +++ ruby-1.8.7-p72/mkconfig.rb Thu Sep 17 07:32:13 2009
>> @@ -55,7 +55,7 @@
>> continued_name = name
>> next
>> end
>> - when /^"(.+)"\s*(\\)?$/
>> + when /^"(.*)"\s*(\\)?$/
>> if continued_line
>> continued_line << $1
>> unless $2
>>
>> -Norm
>>
>>
>> Amanda waite wrote:
>>> Norm Jacobs wrote:
>>>>
>>>> I finally go a chance to finish tracking this down. It appears
>>>> that if the path to your proto area is sized just so, the ruby
>>>> build will generate a config.status that has
>>>> S["CFLAGS"]="....."\
>>>> ""
>>>> in it. later in the ruby build, ruby appears to generate
>>>> rbconfig.rb using a combination of their tools and config.status.
>>>> The continued line "" in config.status appears to confuse their
>>>> parser causing an invalid rbconfig.rb to be generated. Since they
>>>> use rbconfig.rb for the rest of their build, it goes horribly
>>>> wrong. I'm not a ruby god, so it will probably take me a little
>>>> bit to generate a fix. In the meantime, you can workaround this
>>>> (if you run into it) by making your workspace pathname shorter or
>>>> longer.
>>> Do you know what length of path actually causes the issue? If I can
>>> recreate it I might be able to get a handle on the issue.
>>>
>>> Thanks for looking into this, it seems unlikely that I would have
>>> been able to recreate this unless I got really (un)lucky.
>>>
>>> Amanda
>>>
>>>>
>>>> For any ruby gods that want to lend me a clue, the command that
>>>> generates rbconfig.rb is
>>>>
>>>> $ ./miniruby -I./lib -I.ext/common -I./- -r./ext/purelib.rb
>>>> ./ext/extmk.rb --make="/usr/ccs/bin/make" --dest-dir=""
>>>> --extout=".ext" --mflags="" --make-flags="" --extension
>>>> --extstatic --
>>>>
>>>> -Norm
>>>>
>>>>
>>>> Norm Jacobs wrote:
>>>>> Amanda Waite wrote:
>>>>>> I've just built Ruby from an SFW workspace on build 122 on x64
>>>>>> and it all went ok. I'll run nightly tomorrow. I don't expect a
>>>>>> negative result so hopefully Norm has some idea.
>>>>>>
>>>>>> Amanda
>>>>>>
>>>>>> Mike Sullivan wrote:
>>>>>>> Amanda Waite wrote:
>>>>>>>> Hi Milan,
>>>>>>>>
>>>>>>>> I'm just getting my x64 build system updated and will run some
>>>>>>>> tests on a clean workspace tomorrow. The problem maybe to do
>>>>>>>> with the way the build has written it's rbconfig.rb file so the
>>>>>>>> answer maybe further up in the output from the build.
>>>>>>>>
>>>>>>>
>>>>>>> I've only seen this once, in one of norm's builds, and he
>>>>>>> claimed to
>>>>>>> have seen it and have a fix somewhere. So it's probably time to
>>>>>>> hope
>>>>>>> he responds :)
>>>>> I ran across this last week while working on some changes to
>>>>> standardize the individual component build some. I have narrowed
>>>>> it down some, but still haven't had a chance to find the ultimate
>>>>> cuplrit. In my case, It works for me when I set ROOT to a proto
>>>>> area for a workspace without all of my changes. I have some
>>>>> problems with my proto area that I am working out. My workspace
>>>>> has changes to about 200 of the Makefiles that build SFW bits
>>>>> prior to ruby, so the net's pretty big right now. Can you send me
>>>>> a pointer to your system and the workspace that you are having the
>>>>> problems with. It may help me isolate the problem quicker.
>>>>> -Norm
>>>>>
>>>>>>>
>>>>>>> Mike
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Milan Jurik wrote:
>>>>>>>
>>>>>>>>> /export/home/luser/sfwnv/usr/src/cmd/ruby18/ruby-1.8.7-p72/lib/mkmf.rb:1676:in
>>>>>>>>>
>>>>>>>>> `dup': can't dup NilClass (TypeError)
>>>>>>>>>
>>>>>>>>> from
>>>>>>>>> /export/home/luser/sfwnv/usr/src/cmd/ruby18/ruby-1.8.7-p72/lib/mkmf.rb:1676:in
>>>>>>>>>
>>>>>>>>> `init_mkmf'
>>>>>>>>>
>>>>>>>>> from
>>>>>>>>> /export/home/luser/sfwnv/usr/src/cmd/ruby18/ruby-1.8.7-p72/lib/mkmf.rb:1736
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> sfwnv-discuss mailing list
>>>>>> sfwnv-discuss at opensolaris.org
>>>>>> http://mail.opensolaris.org/mailman/listinfo/sfwnv-discuss
>>>>>
>>>>>
>>>>
>>>
>>
>
