On Thursday 27 October 2005 17:10, you wrote: > > No it is not; we've already eliminated that possibility. > > (I want to make sure we are on the same brainwave here) s/brainwave/wavelength/ :-) > This is not related to reducing the command line that mklibs issues to > invoke gcc (that will run the linker) a.k.a. the modifications we made > on mklibs before I decided to just copy all the libs (before > mklibs-copy was available on ppc), right? No, but it is taking the same idea further. > > It could still be that the linker chokes on the mount of symbols that > > are specified for inclusion, but it is not the length of the command > > line as such. > > In other words, somebody managed to regenerate the segfault I got, but > while trying to add the symbols one by one, or even other symbols, but > with a command that was significantly smaller? (Was this with the > patch you proposed for mklibs, the one related to using some files, of > some sort?) Don't know about adding one-by-one. My patch created a linker script (a file) that replaced all the -u<symbol> options with just that filename, reducing the command line from >6000 to about 1000. The linker script contained: EXTERN(<symbol>) EXTERN(<symbol>) EXTERN(<symbol>) EXTERN(<symbol>) ... Effectively this does the same as using -u, but avoids the long command line, thus ruling out that as the cause.
Attachment:
pgpnpAIFbn5zQ.pgp
Description: PGP signature