Bugzilla Bug 125805

We've added support for multiple entries in GCC_SPECS, separated by ":". 
gcc-config currently rejects multiple entries as it checks that ${GCC_SPECS}
exists.

To follow - a patch to gcc-config-1.3.13 so that it checks colon-separated
entries.

Created an attachment (id=81904) [edit]
Check colon-separated entries in GCC_SPECS

Simple enough, I think.  Checks that everything listed in GCC_SPECS exists
either as a full path or relative to LDPATH (so that we can set things like
"nopie.specs:ssp.specs:nonow.specs").

looks sane enough ... i'll touchup syntax and commit it

SpanKY - if you let me know what syntax bits you don't like, I'll update the
patch.

ive added 1.3.15 with support for multiple entries ... please give it a spin
before i move it into ~arch

Created an attachment (id=103677) [edit]
fail if file is missing on all paths, only check this compiler's ld paths,
issue warning if one or more files are missing

Thanks.  A few issues though.  This part:

        ret=0
        ...
                        for p in ${paths} ; do
                                [[ ! -f ${p}/${f} ]] && ret=1 && break 2
                        done
                fi
        done

fails if there's more than one path - the file only has to exist on one of the
paths, not all of them.  That's why I had the logic there the other way around.

Multiple paths occur on multilib, but also when more than one compiler is
installed.  I thought MY_LDPATH would contain just the paths for the selected
compiler, which looking at the code is obviously not the case.   However specs
files are searched for relative olny to the current compiler's libdir(s), so
the files_exist check should only be looking there.

One more thing, is that if any of the files don't exist GCC_SPECS is silently
set to "" - which is fine, but a warning would be useful in that case (since it
implies the config file is out of date/wrong).

I'm not quite up to speed with the workings and effects of multilib; I notice
that the LDPATH for the compiler also includes a '32' subdirectory, which is
not in the compiler library search path - under what situations is this
subdirectory used?

Another way to find the compiler library search paths is to do:

gcc -print-search-dirs | awk '$1=="libraries:" {print $2} | sed -e 's/^=/'

which is where it will actually search for specs files.  Perhaps the output of
this would be better than the MY_LDPATH stuff.

no ... you cant assume gcc is executable

ok, ive fixed up cvs again, see if you're good with that

i didnt realize the logic you were going for because there were no comments ;P

hmm; I should have got back to you ages ago - 1.3.15 is fine.

ok, moved into ~arch