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 attachment 81904 [details, diff] 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 attachment 103677 [details, diff] 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
