From: David R. M. <dr...@fi...> - 2009-10-12 16:01:22
|
Yes, that would be it. Now the issue is: what behavior do we want? I believe that the code was written this way so that whatever gcc* executables Apple shipped, we'd be able to test them and create a virtual package out of them. Can we test them without allowing them to do anything? -- Dave On Oct 12, 2009, at 8:49 AM, monipol wrote: > In VirtPackage.pm: > > if (opendir(DIR, "/usr/bin")) { > for my $gcc (grep(/^gcc/, readdir(DIR))) { > > > On 12/10/2009, at 12:35, Alexander Hansen wrote: > >> It ran for me when I did a "fink list". >> >> David R. Morrison wrote: >>> Oooo, unless it is happening in VirtPackage.pm someplace, or >>> Bootstrap.pm, when trying to test the properties of gcc. >>> >>> When does fink execute this gcc_fakething? Only when compiling >>> something, or does it even do it with something like "fink index"? >>> >>> -- Dave >>> >>> >>> On Oct 12, 2009, at 8:27 AM, David R. Morrison wrote: >>> >>>> OK, that sounds like an error in the compiler_wrapper shell script >>>> which implements the wrapper mechanism for 10.6's gcc. The >>>> script says >>>> >>>> #!/bin/sh >>>> exec /usr/bin/${0##*/} -arch i386 "$@" >>>> >>>> (or -arch x86_64 on 64-bit). I don't speak shell, so I can't >>>> really >>>> tell what this does. >>>> >>>> It is symlinked from executables named cc c++ c++-4.0 c++-4.2 gcc >>>> gcc-4.0 gcc-4.2 g++ g++-4.0 g++-4.2. That would seem to cover all >>>> cases. >>>> >>>> Although I am still mystified about why this would be invoked by >>>> something other than one of the items on that list. >>>> >>>> -- Dave >>>> >>>> >>>> On Oct 12, 2009, at 8:20 AM, Alexander Hansen wrote: >>>> >>>>> I've confirmed this behavior. >>>>> >>>>> -------- Original Message -------- >>>>> Subject: Re: [Fink-beginners] Installing fink on 10.6 >>>>> Date: Mon, 12 Oct 2009 16:42:52 +0200 >>>>> From: Robert Schuster <rxs...@go...> >>>>> To: Alexander Hansen <ale...@gm...> >>>>> References: <92B...@go... >>>>> > >>>>> <4AD...@gm...> >>>>> <EF3...@go...> >>>>> <4AD...@gm...> >>>>> <FBE...@go...> >>>>> <3A5...@gm...> >>>>> <4AD...@gm...> >>>>> <A3D...@go...> >>>>> <4AD...@gm...> >>>>> >>>>> >>>>> >>>>> You can reproduce it like this: >>>>> >>>>> create a file gcc_hello_fink with this content: >>>>> #!/bin/sh >>>>> echo "Hello from fink" >> hello_file >>>>> >>>>> make it executable and place it in /usr/bin then run any fink >>>>> command. >>>>> It will always produce the file hello_file >>>>> >>>>> >>>>> Am 12.10.2009 um 14:41 schrieb Alexander Hansen: >>>>> >>>>>> Robert Schuster wrote: >>>>>>> >>>>>>> I found the problem: >>>>>>> fink runs everything it finds in the PATH that begins with gcc. >>>>>>> Because of that renaming gcc_select to gcc_auswahl didn't >>>>>>> help. I >>>>>>> think it is not a good idea that fink runs everything that >>>>>>> begins >>>>>>> with >>>>>>> gcc. In most cases files beginning with gcc are compilers, but >>>>>>> that >>>>>>> is >>>>>>> not guaranteed and because fink has root privileges this can >>>>>>> have >>>>>>> terrible results. >>>>>>> >>>>>>> >>>>>> I'm not sure that this is exactly what happened--I'm not able to >>>>>> reproduce it, anyway. If that is indeed what happens, then >>>>>> fink could >>>>>> be modified to avoid this. >>>>>> >>>>>> On the other hand, we make no claims that Fink will work >>>>>> properly if >>>>>> you >>>>>> introduce executables into the system area that aren't part of >>>>>> the OS. >>>>>> fink resets the PATH when it operates, so executables that are >>>>>> in, for >>>>>> example, $HOME/bin, won't be visible. |