On Wed, 23 Jan 2013 22:20:56 -0200 Gustavo Sverzut Barbieri <barbi...@profusion.mobi> said:
> Hi all, > > Today I did investigate this issue and the reason is that Debian (and > thus Ubuntu) apply a patch called link_all_deplibs.patch that will > forcefuly disable emitting the .la dependencies (at leas on linux). > They also apply another one to have binaries to never use .la > dependencies. This patch exposes bugs with libraries that are missing > in LIBADD and LDADD of automake. > > this patch is to ltmain.sh and libtool.m4, but even if I copy their > files to Fedora/Arch it's not behaving the same. I'm still > investigating how to force the same behavior everywhere, so we can > have it more consistent. > > As for Ubuntu/Debian patch correctness: although in theory their patch > is valid, it is useless if you use -Wl,--as-neeeded and just makes us > do more work. They carry this patch for some years and libtool > upstream vetoed the inclusion of it (not sure why). well i can see why deb/ubuntu do it.. they are being anal... but reality deb +ubunut+mint+whoever bases from deb carries this "anal" patch and this is probably like 60% of the linux installs out there. :( so it's a reality we have to live with... even our friends at bodhi will have to deal with it too. unless we just give up on supporting linux in general and "make our own distro"... :) > Talking to one friend that used to maintain autotools he mentioned > that even in development (svn) we should not call autoreconf or > autogen.sh. He mentions that the proper usage is to have a single > point to place all files in m4/ (svn) and generate configure. I find > this quite disgusting, but would solve our problem as well. wait.. put ALL the .m4 files that come FROM autoconf/libtool/automake etc. inside out m4/ dir - ie copy them in? duplicate them? > Regards, > -- Gustavo > > > On Wed, Jan 23, 2013 at 12:04 PM, Gustavo Sverzut Barbieri > <barbi...@profusion.mobi> wrote: > > On Wed, Jan 23, 2013 at 11:15 AM, Ulisses Furquim > > <ulis...@profusion.mobi> wrote: > >> Hi Raster, > >> > >> On Wed, Jan 23, 2013 at 3:05 AM, Carsten Haitzler <ras...@rasterman.com> > >> wrote: > >>> On Tue, 22 Jan 2013 22:16:06 -0200 Ulisses Furquim > >>> <ulis...@profusion.mobi> said: > >>> > >>>> Hi, > >>>> > >>>> On Tue, Jan 22, 2013 at 10:10 PM, Carsten Haitzler <ras...@rasterman.com> > >>>> wrote: > >>>> > On Tue, 22 Jan 2013 21:59:35 -0200 Gustavo Sverzut Barbieri > >>>> > <barbi...@profusion.mobi> said: > >>>> > > >>>> >> On Tue, Jan 22, 2013 at 9:48 PM, Enlightenment SVN > >>>> >> <no-re...@enlightenment.org> wrote: > >>>> >> > Log: > >>>> >> > sorry - have to revert this as this brings the efl tree build to a > >>>> >> > grinding halt - it wasn't great before.. but now it's totally > >>>> >> > broken. : ( e.g.: > >>>> >> > > >>>> >> > /bin/bash ../libtool --tag=CC --mode=link ccache gcc -std=gnu99 > >>>> >> > -O2 -g -pipe -march=native -fvisibility=hidden -ffast-math -W > >>>> >> > -Wall -Wextra -Wno-shadow -Wno-unused-but-set-parameter -o > >>>> >> > bin/eet/eet bin/eet/bin_eet_eet-eet_main.o -fvisibility=hidden > >>>> >> > -fdata-sections -ffunction-sections -Wl,--gc-sections > >>>> >> > -fno-strict-aliasing -Wl,--as-needed > >>>> >> > -Wl,--no-copy-dt-needed-entries lib/eet/libeet.la > >>>> >> > > >>>> >> > libtool: link: ccache gcc -std=gnu99 -O2 -g -pipe -march=native > >>>> >> > -fvisibility=hidden -ffast-math -W -Wall -Wextra -Wno-shadow > >>>> >> > -Wno-unused-but-set-parameter -o bin/eet/.libs/eet > >>>> >> > bin/eet/bin_eet_eet-eet_main.o -fvisibility=hidden -fdata-sections > >>>> >> > -ffunction-sections -Wl,--gc-sections -fno-strict-aliasing > >>>> >> > -Wl,--as-needed -Wl,--no-copy-dt-needed-entries > >>>> >> > lib/eet/.libs/libeet.so /usr/bin/ld: bin/eet/bin_eet_eet-eet_main.o: > >>>> >> > undefined reference to symbol 'eina_iterator_next' > >>>> >> > /usr/bin/ld: note: 'eina_iterator_next' is defined in DSO > >>>> >> > /usr/local/lib/libeina.so.1 so try adding it to the linker > >>>> >> > command line /usr/local/lib/libeina.so.1: could not read symbols: > >>>> >> > Invalid operation collect2: ld returned 1 exit status > >>>> >> > >>>> >> do you know how to force ubuntu's behavior? > >>>> > > >>>> > i actually don't :( it's not just ubuntu - debian, fedora etc. have > >>>> > this on too > >>>> > - fedroa i think was the first to start doing this. > >>>> > > >>>> >> I tried to compile in Fedora because it should alarm the same about > >>>> >> DSO, but it didn't, so passing on Arch and Fedora I did the commit. > >>>> > > >>>> > weird > >>>> > >>>> I also don't see any problem here on Fedora. > >>>> > >>>> >> In theory the -Wl,--no-copy-dt-needed-entries should force that, but > >>>> >> seems it did not. It would be nice to have our build strict and > >>>> >> consistent everywhere, but we need to know how to force the linker to > >>>> >> be like that. > >>>> > > >>>> > indeed - i agree. it seems ubuntu is being much stricter. i totally > >>>> > agree. we just have to have stuff build at all for now. i think the > >>>> > FIRSt port of call actually should be fixng linking to link to in-tree > >>>> > libs not to system libs. makybe make sume dummy "broken" libeina/evas/ > >>>> > whatevrer .so's with ZERO symbols and install those on the build > >>>> > box... and go from there. then if it links to the system ones - > >>>> > linking will break as they provide zero symbols. ALSO don't LINK any > >>>> > of these to any other libs.. so you'll simulate dso strictness :) > >>>> > >>>> And I also never saw any issues like linking to system libs or > >>>> anywhere else besides the building tree. I really don't know what is > >>>> the problem but it seems it just works for me. > >>> > >>> i literally got the DSO errors and look at this: > >>> > >>> note: 'eina_iterator_next' is defined in DSO /usr/local/lib/libeina.so.1 > >>> > >>> thats the system installed lib... i literally got other build problems > >>> today (separate from this one) due to it linking to the installed libevas > >>> not the in efl tree one - i deleted my system libevas.so* and i could do > >>> the build. i don't know what/why - i wake up and have these build > >>> problems... :( > >> > >> Don't know what's happening there. Hopefully Gustavo can sort it out. > >> It just works for me and did test and asked Gustavo if this was right > >> because I do have other versions installed here. :-/ > > > > I also do, I have 1.7 in my /usr/lib and svn into /tmp/efl-install/lib. > > > > -- > > Gustavo Sverzut Barbieri > > http://profusion.mobi embedded systems > > -------------------------------------- > > MSN: barbi...@gmail.com > > Skype: gsbarbieri > > Mobile: +55 (19) 9225-2202 > > > > -- > Gustavo Sverzut Barbieri > http://profusion.mobi embedded systems > -------------------------------------- > MSN: barbi...@gmail.com > Skype: gsbarbieri > Mobile: +55 (19) 9225-2202 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) ras...@rasterman.com ------------------------------------------------------------------------------ Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
