* Peter Ekberg wrote on Tue, Aug 09, 2005 at 02:40:36PM CEST: > Ralf Wildenhues wrote: > > > > I believe your patch and Keith's proposed patch for "-sobase" interact > > (i.e., -sobase support would have to be forward ported into > > your patch.) > > Seems like a simple s/libname/sobase_name/ but someone has to > remember to do it...
Kind of like that. Plus maybe run a test. > > > The "lib as archiver" patch is still needed though, as > > > this seems like the easiest way to get at all symbols > > > from a library with so many objects that the max command > > > line length is exceeded (pdemo.test), as the Microsoft > > > linker does not seem to support reloadable objects. > > > You *could* extract symbols from one object at a time > > > and merge the outcome, but I think that would be a much > > > bigger change. > > > > I'm still not convinced that we don't end up having more trouble with > > paths encoded into the archive. But since "lib" does that anyway, I > > guess we might just have to care for all bad cases (see that we don't > > encode paths, but expect encoded paths in other libs). > > > > I must admit I haven't checked your patch closely w.r.t this yet. > > In the patch, the archive built to get the symbols is not used > for anything but getting the symbols. But two features in lib > are used that are not supported by ar. Namely that lib can take > a command file with inputs (@cmdfile notation) so that the > command line length is short, and the fact that the path is indeed > stored in the archive, so that object file renaming is not needed > for this temporary symbol extracting archive. Can we get in the position that both might be used ("lib" in older, already installed libs, "ar" for a newer package the user is about to link)? I believe not, but need to check so. > So, for this, it is not really needed to have AR=lib. It is perhaps > cleaner to look up "lib" (or "link -lib") and use that without looking > at $AR at all, since ar does not have the required functionality. This is precisely what kind of bugs me. We don't want to prevent use of a GNU tool here. > When doing the actual linking, a command file is again used, > so it's similar to the linker script approach taken with gnu ld. > (except that the linker script isn't used with gnu ld when the > command line length is overrun in the extract symbol step, in > that case the reloadable object file is used for both symbol > extraction and actual link) OK. Cheers, Ralf