Nicolas Williams wrote: > Well, but ISTM that it should check the scope of the symbols it finds in > the global symbol table, otherwise... what's the point of allowing one > to modify symbol scope via elfedit(1)? And if there's some other good > reason for allowing this in elfedit then at least a warning would be > useful.
ld.so.1 would have to do a little more. Don't forget, if you create a shared object that references a global symbol within the shared object, a .plt is created - at runtime you'll go through ld.so.1 to resolve the call to yourself. In this case, ld.so.1 wouldn't want to forbid resolving to a local symbol :-) But if you go through this .plt could you be interposed on ? :-) > Let's put it this way: I find the current situation confusing, but I > shouldn't have been confused. elfedit(1) is going to let you hang yourself :-). You can change just about anything, and we've nowhere near the verification that would come close to cover all that could be changed (damaged). We've tried to document "useful" scenarios, ie. those that we've heard folks ask for, and things that we developers do from day to day to kick the tires, but we've also opened a flood gate of unknown changes. Some will prove useful. As we learn of new user requirements we might be able to "package a family of changes" into one elfedit instruction. We're still learning. > I'll go find out how to get libtool to use a mapfile, and how to file a > bug against it if it can't easily be made to use mapfiles. I spent a > few minutes this weekend on searching for libtool and mapfile, and not > finding the answer; I'll spend more time on that this time. You can always set LD_OPTIONS=-Mmapfile before calling any makefiles or build shell scripts and pass additional information to the underling link-edit that will be called. > BTW, I rather expect that we'll see a lot more of this as we add more > and more libtool-using FOSS to SFW. Yes. We've both excited and afraid of this :-) -- Rod
