On Sun, 27 May 2018 11:51:31 +0000 Daniel Zaoui <jackdani...@eyomi.org> said:
> On Sun, 27 May 2018 12:55:02 +0900 > Carsten Haitzler (The Rasterman) <ras...@rasterman.com> wrote: > > > On Sat, 26 May 2018 22:37:13 +0100 Al Poole <nets...@gmail.com> said: > > > > > Hi raster, > > > > > > The commit: > > > > > > 757f7a7279e97e80ccb4defa986c174daaf9449e > > > > > > Breaks module loading on FreeBSD. > > > > > > Lots of unresolved symbols when loading modules: E initialzation > > > loops forever. > > > > > > I thought about reverting but perhaps you have the time to > > > investigate the issue there? > > > > oh really? it worked perfectly on linux... why would it break on bsd. > > RTLD_LOCAL according to the man pages doesn't make symbols available > > globally (so regular sym lookups wont find those symbols in the > > global table - they must be dlsym()'d from the module handle). the > > man page here says: > > > > RTLD_LOCAL > > This is the converse of RTLD_GLOBAL, and the default > > if neither flag is specified. Symbols defined in this shared > > object are not made available to resolve references in subsequently > > loaded shared objects. > > > > right now i'm chasing an efl break that destroys compositing in e > > after a little time (open a few windows, switch desktops) where all > > my windows become garbage. something between > > ea1760380e34074d9e6b9633a54a4f9c27e64aec and > > 75bb7c049f05176aef635bddcfb320c306b196bf. > > I have the same issue. bisect doesn't work well on Cedric 121 patches. Sucks. > Anyway, I opened a ticket (T6970). yeah. it's impossible to find the issue. well not without spending weeks going over every commit with a fine tooth comb and getting lucky. boiling it down to 1 commit isn't possible it seems, so the person with the knowledge of the changes might have a better chance. but otherwise i'm going to have to revert all of this and anything that depends on these changes after it too just to get back to a working state. i'm waiting until mid next week to see if things get fixed > > in the meantime could you look into why freeebsd is different here? > > it sounds like it's interpreting RTLD_LOCAL to not resolve symbols > > within the module using the global context which is not what the > > above says... what symbols are not looking up? stuff in e? like e_* > > ones? i am guessing that it's these. > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- Carsten Haitzler - ras...@rasterman.com ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
