* Albert Chin wrote on Thu, Aug 17, 2006 at 07:55:14AM CEST: > On Thu, Aug 17, 2006 at 07:42:00AM +0200, Ralf Wildenhues wrote: > > > But say, why is -Wl,-E not passed to the link line? It should be > > export_dynamic_flag_spec. And it should have the desired effect: > > | -E Mark all symbols defined by a program for export > > | to shared libraries. In a +compat mode link, ld > > | marks only those symbols that are actually > > | referenced by a shared library seen at link time. > > | In a +std link, all symbols are exported by > > | default, so -E is not necessary to make symbols > > | visible. However, it has an additional side > > | effect of identifying all exported symbols as > > | necessary, so that they will not be removed when > > | using dead code elimination (+Oprocelim). > > Because -export-dynamic is not specified.
It should not need to be. IOW, either the Libtool documentation or the implementation is broken: | `-dlopen FILE' | Same as `-dlpreopen FILE', if native dlopening is not supported on | the host platform (*note Dlopened modules::) or if the program is | linked with `-static', `-static-libtool-libs', or `-all-static'. | Otherwise, no effect. If FILE is `self' Libtool will make sure | that the program can `dlopen' itself, either by enabling | `-export-dynamic' or by falling back to `-dlpreopen self'. But anyway, if you have other modules, you should specify -export-dynamic, I think. At least I can't infer from the above snippet that `-dlopen self' would be sufficient. What do you think? > > Otherwise, -Wl,+Onoprocelim should be the hammer we're looking for, I > > guess; but that should not even be necessary, given above documentation > > (from ld(1)). > > Well, export_dynamic_flag_spec isn't even looked at when -dlopen self > is being handled. Maybe it should and only use the -dlopen self code > when export_dynamic_flag_spec is empty? I still need to look at that code. > If not, looks like we'll need to add +Onoprocelim to the cc > command-line for HP-UX. What's the best way to do this? A new > variable? Let's better not go that route, if we can avoid it. But yes, then a new variable would be good. Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
