I see another response on this thread makes this moot, but in case it helps with anything... On Wed, 2017-01-11 at 17:40 +0000, Andrew Haley wrote: > > > > Stripping the debug info, while possible, might be tricky because I > > don't necessarily know all the files from GCC which get linked into my > > app. And while I can try to find them now, I worry that over time > > others might get linked in. I don't suppose there's an easy way to > > systematically strip it out from all libs that GCC produces (ie. without > > necessarily specifying each obj or lib file)? > > Surely it's a 15-minute job to write a find script. Although, yeah, > they always take longer than I expect, but this is a really easy > job. Writing the script will be easy. My question here is more about if there exists some methodology which makes the script somewhat future-proof. For example, "strip all objs and libs in dirs A, B, C...". I supposed I can use the file command to identify the file type and strip all objs and libs found within the PREFIX tree. > No, it's in the makefiles, so it can be done. But there are lots of > FLAGS variables in the scripts, and these will change with future > versions of GCC. That's why post-processing is probably your best > bet. I noticed that "-g" was inside the Makefile that's generated from running configure. Removing the flag from that file (in all locations) removed it for much of the GCC build, but there were still some other places where it was used. Not sure if any of those amount to objs/libs that would get linked into generated apps.
