ASSP port testing, not getting all perl mods to work

[Frank J. R. Hanstick]

Hello,
	The problem I had with two gcc's was that one call to the gcc was  
done direct (gcc) instead of an indirect prefix variable [ ($SRC) 
gcc ].  I would look into ASSP to be sure that all calls to perl  
modules use the indirect method.  There may be some elements where  
the call is direct (using the pathname) rather than using the  
indirect "I told you where to look".  If the three offending calls  
use the direct method, then those need to be changed to indirect.   
The behavior you describe points to what I have seen.  I may be  
wrong; but, it is a place to start.
Frank

On Jan 21, 2009, at 5:23 PM, Scott Haneda wrote:

> I am telling ASSP where the new perl is, this issue is that some  
> modules, only three of 15 or more, are being looked for in the  
> wrong spot.
>
> I do not know if I should solve this in the port, by editing the  
> source of the app, or if there is some other way.  I actually hope  
> there is some other way, as there should be no reason why I need to  
> modify the source other than to change the perl path at the top of  
> a few files.
>
> On Jan 21, 2009, at 5:13 PM, Frank J. R. Hanstick wrote:
>
>> Hello,
>> 	It sounds like opt/local is not the first location the path  
>> environment looks for perl.  This is a problem when several  
>> versions of a program exists because unless a prefix is supplied,  
>> the default program will always be found in the order of the  
>> pathname (first detected).  If perl exists in /opt/local/bin and / 
>> usr/bin and the path is in the order of /usr/bin:/opt/local/bin,  
>> then without a prefix, /usr/bin will always be the perl used and  
>> visa versa if path is /opt/local/bin:/usr/bin.  I ran into the  
>> same problem with gcc located in two different locations.
>> Frank
>
> --
> Scott
>