Relocation/symlink confusion (was Re: Does kernel use system stdarg.h?)

[Daniel Jacobowitz <dan at debian dot org>]

On Mon, Sep 30, 2002 at 10:58:47AM -0200, Denis Vlasenko wrote:
> This is slightly offtopic, but since this issue cropped up
> when I tried to build 2.5 on a box which builds 2.4
> just fine I post it here. BTW, if someone knows
> GCC mailing list addr to send this, please let me know it.

gcc-bugs@gcc.gnu.org.  Simple!

> Heh. I believe that my GCC installation is okay, but slightly unusual:
> 
> /usr/bin/gcc is a symlink: -> /usr/app/gcc3.0.3posix/bin/gcc
> /usr/app/gcc -> /usr/app/gcc3.0.3posix
> /usr/sbin -> /usr/bin
> PATH=/home/vda/bin:/sbin:/usr/sbin:/bin:/usr/bin
> 
> so when I run gcc it actually runs /usr/sbin/gcc. Am I weird? ;)

Yes, you're wierd.  I believe GCC doesn't support replacing the binary
with a symlink.  If you use a shell script wrapper instead or something
along those lines, it'll probably work...

I don't know if GCC should handle this or not.

> 
> GCC developers did not expect it and when GCC tries to internally
> add -iprefix to the commandline it looks for $GCC_EXEC_PREFIX
> in environment and, failing that, takes gcc startup path
> as a base. That's where /usr/sbin came into gcc commandline.
> 
> This is IMHO wrong. Most other programs hardcode their installation paths
> as directed at configure time (still not good, you cannot move installed 
> binaries without breaking things) or have small $PACKAGE-config script
> which spits out paths to the stdio (I like this!).
> I have 38 *-config* files in my /usr/bin so I think it is an accepted
> practice.
> 
> When I built GCC (a while ago) I hoped it will take at least route of
> hardcoding paths and ./configured it this way:
> Configured with: ../gcc-3.0.3/configure
> --prefix=/usr/app/gcc-3.0.3posix
> --exec-prefix=/usr/app/gcc-3.0.3posix
> --bindir=/usr/app/gcc-3.0.3posix/bin
> --libdir=/usr/lib
> --infodir=/usr/app/gcc-3.0.3posix/info
> --mandir=/usr/app/gcc-3.0.3posix/man
> --with-slibdir=/usr/lib
> --with-local-prefix=/usr/local
> --with-gxx-include-dir=/usr/include/g++-v3
> --enable-threads=posix
> but as it turns out this is not enough.
> 
> For time being I run kernel make like this:
> 
> GCC_EXEC_PREFIX=/usr/app/gcc/lib/gcc-lib/ make ... ... ...
> 
> BTW, here is gcc.c source snippet which sets up -iprefix:
> =========================================================
>   /* Set up the default search paths.  If there is no GCC_EXEC_PREFIX,
>      see if we can create it from the pathname specified in argv[0].  */
> 
> #ifndef VMS
>   /* FIXME: make_relative_prefix doesn't yet work for VMS.  */
>   if (!gcc_exec_prefix)
>     {
>       gcc_exec_prefix = make_relative_prefix (argv[0], standard_bindir_prefix,
> 					      standard_exec_prefix);
>       //printf("vda: gcc_exec_prefix 2:%s\n",gcc_exec_prefix);
> 					      
>       if (gcc_exec_prefix)
> 	putenv (concat ("GCC_EXEC_PREFIX=", gcc_exec_prefix, NULL_PTR));
>     }
> #endif
> 
>   if (gcc_exec_prefix)
>     {
>       int len = strlen (gcc_exec_prefix);
> 
>       if (len > (int) sizeof ("/lib/gcc-lib/") - 1
> 	  && (IS_DIR_SEPARATOR (gcc_exec_prefix[len-1])))
> 	{
> 	  temp = gcc_exec_prefix + len - sizeof ("/lib/gcc-lib/") + 1;
> 	  if (IS_DIR_SEPARATOR (*temp)
> 	      && strncmp (temp + 1, "lib", 3) == 0
> 	      && IS_DIR_SEPARATOR (temp[4])
> 	      && strncmp (temp + 5, "gcc-lib", 7) == 0)
> 	    len -= sizeof ("/lib/gcc-lib/") - 1;
> 	}
> 
>       set_std_prefix (gcc_exec_prefix, len);
>       add_prefix (&exec_prefixes, gcc_exec_prefix, "GCC",
> 		  PREFIX_PRIORITY_LAST, 0, NULL_PTR);
>       add_prefix (&startfile_prefixes, gcc_exec_prefix, "GCC",
> 		  PREFIX_PRIORITY_LAST, 0, NULL_PTR);
>     }
> --
> vda
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer