On 6/23/13 11:15 AM, Daniel Johnson wrote:
>
> On Jun 23, 2013, at 1:06 PM, Alexander Hansen <alexanderk.han...@gmail.com>
> wrote:
>
>> On 6/23/13 8:45 AM, Alexander Hansen wrote:
>>> On 6/23/13 7:04 AM, Alexander Hansen wrote:
>>>> On 6/23/13 6:55 AM, Daniel Johnson wrote:
>>>>>
>>>>> On Jun 20, 2013, at 9:55 PM, Alexander Hansen
>>>>> <alexanderk.han...@gmail.com> wrote:
>>>>>
>>>>>> On 6/19/13 8:03 PM, Alexander Hansen wrote:
>>>>>>> 1) I've finally smoothed some tuits down enough to work on
>>>>>>> https://github.com/fink/fink/issues/42 . This is going use a similar
>>>>>>> methodology as the system-SDK packages, in that we're not going to
>>>>>>> have
>>>>>>> system-javaXY packages present at all for systems where one cannot
>>>>>>> possibly have that XY (e.g. system-java13 on Mountain Lion). Having a
>>>>>>> virtual package present but not installed produces a confusing faux
>>>>>>> build process when installing something that depends on it, whereas
>>>>>>> not
>>>>>>> having an entry for the package gives a straightforward "package does
>>>>>>> not exist" message.
>>>>>>> Once I've got something that WorksForMe on different platforms, I'll
>>>>>>> put
>>>>>>> it in a branch of the main fink repository.
>>>>>>>
>>>>>>
>>>>>> Meh, I just put it in master. User-visible changes are:
>>>>>>
>>>>>> 1) For people on 10.7 or later who have Oracle's Java-1.7.x installed,
>>>>>> there will be system-java17* packages, plus the system-java and
>>>>>> system-java-dev package will exist for people who don't have a legacy
>>>>>> Apple Java installed, e.g. people who installed Mountain Lion after
>>>>>> Apple dropped it.
>>>>>>
>>>>>> 2) On 10.5/i386, system-java16* goes away because Java-1.6.x was
>>>>>> distributed as x86_64 only for some reason there.
>>>>>
>>>>> Your commit bffa85c appears broken. I'm getting a lot of these every
>>>>> time I run fink:
>>>>>
>>>>> Use of uninitialized value $dir in concatenation (.) or string at
>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 420.
>>>>> Use of uninitialized value $dir in concatenation (.) or string at
>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 421.
>>>>> Use of uninitialized value $dir in concatenation (.) or string at
>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 427.
>>>>> Use of uninitialized value $dir in pattern match (m//) at
>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 433.
>>>>> Use of uninitialized value $dir in concatenation (.) or string at
>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 420.
>>>>> Use of uninitialized value $dir in concatenation (.) or string at
>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 421.
>>>>> Use of uninitialized value $dir in concatenation (.) or string at
>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 427.
>>>>> Use of uninitialized value $dir in pattern match (m//) at
>>>>> /sw64/lib/perl5/Fink/VirtPackage.pm line 433.
>>>>>
>>>>> Looks like $dir is no longer in scope?
>>>>>
>>>>> Daniel
>>>>>
>>>>
>>>> Hmm...I'm not seeing that here, and I've got both a legacy and a new JDK
>>>> so I thought I had full coverage :-) .
>>>>
>>>> What does "/usr/libexec/java_home -V" return?
>>>>
>>>
>>> And what OS version?
>>>
>>
>> $dir is still in scope at line 420. It gets redefined, and potentially
>> undefined, now that I look at it, at line 406 for 1.7.x JDKs:
>>
>> ($dir) = ($javadir =~ m|jdk(\d.*)_|) ;
>
>
> I get
>
> Matching Java Virtual Machines (5):
> 1.7.0_06, x86_64: "Java SE 7"
> /Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home
> 1.7.0_04, x86_64: "Java SE 7"
> /Library/Java/JavaVirtualMachines/1.7.0.jdk/Contents/Home
> 1.7.0-u4-b05-20120111, x86_64: "OpenJDK 7"
> /Library/Java/JavaVirtualMachines/1.7.0u.jdk/Contents/Home
> 1.6.0_51-b11-456, x86_64: "Java SE 6"
> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
> 1.6.0_51-b11-456, i386: "Java SE 6"
> /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
>
> /Library/Java/JavaVirtualMachines/jdk1.7.0_06.jdk/Contents/Home
>
> Interesting that I have multiple 1.7.0's showing.
>
> This is on 10.8.4 with Xcode 4.6.3.
> The issue goes away when I roll back to before the java commits.
>
> Daniel
>
The issue would indeed go away, because 1.7.x isn't detected at all. :-)
The multiple 1.7.0 JDKs is completely normal. This appears to be the
same strategy that has been used on Windows all along.
(One annoyance is that the auto-update for Java (via the Control Panel)
seems only to update the browser plugin and not the JDK.)
I have:
$ /usr/libexec/java_home -V
Matching Java Virtual Machines (4):
1.7.0_25, x86_64: "Java SE 7"
/Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home
1.7.0_21, x86_64: "Java SE 7"
/Library/Java/JavaVirtualMachines/jdk1.7.0_21.jdk/Contents/Home
1.6.0_51-b11-456, x86_64: "Java SE 6"
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
1.6.0_51-b11-456, i386: "Java SE 6"
/System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
and I naively assumed that the path structure wasn't changed along the way.
So the issue appears to be that your OpenJDK and 1.7.0_4 JDK paths don't
satisfy the regex and $dir winds up getting unset.
--
Alexander Hansen, Ph.D.
Fink User Liaison
My package updates: http://finkakh.wordpress.com/
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
fink-core mailing list
fink-core@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.core
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-core
