Gilles Chanteperdrix wrote: > Jan Kiszka wrote: >> Gilles Chanteperdrix wrote: >>> Jan Kiszka wrote: >>>> Gilles Chanteperdrix wrote: >>>>> Jan Kiszka wrote: >>>>>> And instantly - you forget about dlopen scenarios which triggered the >>>>>> bug in timeconv. >>>>> I do not see why dlopen would trigger a bug. Could you explain it? >>>> If you dlopen, say, libnative and call a symbol that uses some timeconv >>>> constants, you have to make sure that the init code of libnative >>>> initializes those variables that are later used. >>> That is where I do not follow you. dlopen is called after the startup of >>> the other libs, so either it references its own variables, which are >>> initialized once its constructor has been called. Or it references the >>> variables of the posix lib (only native and posix use timeconv in >>> user-space) which is already initialized. >> In this case, dlopen was part of some constructor, and the ordering >> turned out to be "unfortunate". > > Ok. Got it now. Will test your patch, but I will probably leave the weak > attribute to the shared functions.
Well, either all or nothing: If you leave it to the runtime services, you also have to tag the init function (that's what my very first tiny patch did). Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
