Re: [E-devel] 1.22 work items list
Hello. With beta 1 out I wanted to share some updates here. On 28.02.19 17:45, Stefan Schmidt wrote: > Freeze is on and while the tarballs might be delayed we can already look > forward and define what needs to be done in the stabilization phase to > make this release solid. > > First of all I would like to ask everybody to look at the bugs tagged > with efl-1.22 in showstopper and high priority: > > https://phab.enlightenment.org/maniphest/query/AWWSVak2wbzc/ > > 16 showstopper issues > 20 high priority issues The raw showstopper number has been going down to 13. But there are certainly some on the list which I would not consider a blocker for the release. My current personal shortlist of must-somehow-deal-with bugs are: https://phab.enlightenment.org/T7360 Evas/Edje animations not in sync Tagged as regression https://phab.enlightenment.org/T7100 Performance issue when closing the menu Tagged as performance regression https://phab.enlightenment.org/T7292 Elementary test genlist crash, freeze and other bugs https://phab.enlightenment.org/T7269 Maximized internal wins dont return to their previous size after unmaximize Tagged as regression > Everybody can help here and it would really be appreciate if I don't > have to chase people looking at them. > > In addition to this we should get some more tooling running on the code > base to find out where we stand. > > 1) Running the ABI/API checker to find all new API and discuss them if > needed. Also checking if we have regressions in removed APIs. See the other mail I sent about this topic. Look over the report and fix issues you find or start a discussion if you are not sure what to do about it. https://abi-laboratory.pro/index.php?view=objects_report=efl=1.21.1=1.22.0-beta1 > 2) Running Coverity to have some additional static analysis on the code > to see if it finds any critical issues we should fix before the release. I had runs for alpha and beta1 submit and they have been analyzed. Chris started to look through seem and submitting fixes. Thanks a lot! I still see 30 high impact issues listed there. Resource leaks, memory corruptions, etc. We should aim to have at least these fixed before we release. This could use more hands as well. Maybe only look at your area of expertise and work on those places in the tree. regards Stefan Schmidt ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] 1.22 work items list
On 05/03/2019 07:07, Marcel Hollerbach wrote: On 3/4/19 9:13 PM, Ross Vandegrift wrote: - no static libs are generated. Is that intentional. Which static libs are you refering to ? Most static libs that we have are only used in 1 place, and are added via a dependency and source code, i don't really have a strong reason why I did it like this, if this is a issue, it can be changed quickly :) With autotools, --enable-static would output static libs along with the shared objects for all of EFL. Debian packages often ship static libs in the -dev packages, EFL included. If static EFL libs should be deprecated that's probably okay - I don't know that anyone is using the static libs we ship. Has anyone a comment on this? How should we handle this ? I think dropping support is reasonable, most distro's don't ship them and the only reason you'd use them is if you want to build your app against static efl to make it easier to ship outside of standard package management. But the proprietary users who may consider doing this quite probably wouldn't due to efl's licensing. So documenting it in the release notes is probably the only action required -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] 1.22 work items list
On 3/4/19 9:13 PM, Ross Vandegrift wrote: > On Mon, Mar 04, 2019 at 04:58:24PM +0100, Marcel Hollerbach wrote: >>> On 03.03.19 21:49, Ross Vandegrift wrote: The build fails on evas modules when linking with -Wl,-z,defs. Example failure below. I tried adding evas to the dependencies, but couldn't get it working. Disabled strict linking for now just to get through a build. Some questions about the result: >> >> Strict linking is something we could not achive for now, due to the fact >> that our evas source code structure and the way meson works is a little >> bit of a pain to get in sync. This is also the reason why evas_loaders / >> savers are only build statically, for now. The rendering engines can be >> both, either static or shared. Same for emotion players. > > I see. Strict linking isn't really a requirement for us, just a nice to > have. Sounds like we should drop -Wl,-z,defs when the meson switch > hapens. We can always add it back if/when the situation improves. > - evas loaders/savers modules aren't generated. Maybe built static in spite of -Devas-modules=shared? - maybe the same issue with emotion players > > And that means these are on purpose. > - no static libs are generated. Is that intentional. >> >> Which static libs are you refering to ? Most static libs that we have >> are only used in 1 place, and are added via a dependency and source >> code, i don't really have a strong reason why I did it like this, if >> this is a issue, it can be changed quickly :) > > With autotools, --enable-static would output static libs along with the > shared objects for all of EFL. Debian packages often ship static libs > in the -dev packages, EFL included. If static EFL libs should be > deprecated that's probably okay - I don't know that anyone is using the > static libs we ship. Has anyone a comment on this? How should we handle this ? > - shaders aren't regenerated w/EFL_SHD_REGEN. Easy to workaround, but just want to make sure that's expected. >> >> Yes, this is kind of intentional, regernerading the shader code is just >> a shell script, if someone wants to execute it, feel free, but i don't >> think we need a target for that ? If we do, then same as before, it can >> be changed quickly :) > > Agreed, no target is needed. Just noticed that it's different from > autotools build. > > > So: I'd say the meson build looks pretty good. Just a few small tweaks > for us when the switch happens. > Thats really nice to hear, thx! :) Greetings, bu5hm4n > Thanks for the help, > Ross > > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > pEpkey.asc Description: application/pgp-keys ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] 1.22 work items list
On Mon, Mar 04, 2019 at 04:58:24PM +0100, Marcel Hollerbach wrote: > > On 03.03.19 21:49, Ross Vandegrift wrote: > >> The build fails on evas modules when linking with -Wl,-z,defs. Example > >> failure > >> below. I tried adding evas to the dependencies, but couldn't get it > >> working. > >> > >> Disabled strict linking for now just to get through a build. Some > >> questions > >> about the result: > > Strict linking is something we could not achive for now, due to the fact > that our evas source code structure and the way meson works is a little > bit of a pain to get in sync. This is also the reason why evas_loaders / > savers are only build statically, for now. The rendering engines can be > both, either static or shared. Same for emotion players. I see. Strict linking isn't really a requirement for us, just a nice to have. Sounds like we should drop -Wl,-z,defs when the meson switch hapens. We can always add it back if/when the situation improves. > >> - evas loaders/savers modules aren't generated. Maybe built static in > >> spite of > >> -Devas-modules=shared? > >> - maybe the same issue with emotion players And that means these are on purpose. > >> - no static libs are generated. Is that intentional. > > Which static libs are you refering to ? Most static libs that we have > are only used in 1 place, and are added via a dependency and source > code, i don't really have a strong reason why I did it like this, if > this is a issue, it can be changed quickly :) With autotools, --enable-static would output static libs along with the shared objects for all of EFL. Debian packages often ship static libs in the -dev packages, EFL included. If static EFL libs should be deprecated that's probably okay - I don't know that anyone is using the static libs we ship. > >> - shaders aren't regenerated w/EFL_SHD_REGEN. Easy to workaround, but just > >> want to make sure that's expected. > > Yes, this is kind of intentional, regernerading the shader code is just > a shell script, if someone wants to execute it, feel free, but i don't > think we need a target for that ? If we do, then same as before, it can > be changed quickly :) Agreed, no target is needed. Just noticed that it's different from autotools build. So: I'd say the meson build looks pretty good. Just a few small tweaks for us when the switch happens. Thanks for the help, Ross ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] 1.22 work items list
Hi, On 3/4/19 11:27 AM, Stefan Schmidt wrote: > Hello Ross > > On 03.03.19 21:49, Ross Vandegrift wrote: >> On Thu, Feb 28, 2019 at 05:45:29PM +0100, Stefan Schmidt wrote: >>> For packagers I would like to remind that this release will use the >>> autotools builds system as official base. Tarballs will be generated >>> with. We will also provide meson generated tarballs where we would >>> appreciate testing (Simotek already promised to do that on OpenSUSE, >>> other are more than welcome). This is especially critically as we will >>> remove the autotools build system completely from master after this >>> release is out. It will only remain in the efl-1.22 stable branch at >>> that point. Don't stay behind and make sure your use cases are covered >>> with meson. >> >> Thanks Stefan. I tested 1.22.0-alpha1 from git with the Debian packaging. >> >> The build fails on evas modules when linking with -Wl,-z,defs. Example >> failure >> below. I tried adding evas to the dependencies, but couldn't get it working. >> >> Disabled strict linking for now just to get through a build. Some questions >> about the result: Strict linking is something we could not achive for now, due to the fact that our evas source code structure and the way meson works is a little bit of a pain to get in sync. This is also the reason why evas_loaders / savers are only build statically, for now. The rendering engines can be both, either static or shared. Same for emotion players. >> - evas loaders/savers modules aren't generated. Maybe built static in spite >> of >> -Devas-modules=shared? >> - maybe the same issue with emotion players >> - no static libs are generated. Is that intentional. Which static libs are you refering to ? Most static libs that we have are only used in 1 place, and are added via a dependency and source code, i don't really have a strong reason why I did it like this, if this is a issue, it can be changed quickly :) >> - shaders aren't regenerated w/EFL_SHD_REGEN. Easy to workaround, but just >> want to make sure that's expected. Yes, this is kind of intentional, regernerading the shader code is just a shell script, if someone wants to execute it, feel free, but i don't think we need a target for that ? If we do, then same as before, it can be changed quickly :) > Thanks a lot for taking the time to test the meson setup with Debian. > Appreciated. > > Seems strict linking is something we have not yet tested with our meson > build. Good to know. I will see that we have a look at this. > > regards > Stefan Schmidt > Greetings, bu5hm4n >> Ross >> >> >> >> FAILED: src/modules/evas/engines/buffer/libbuffer.so >> ccache cc -o src/modules/evas/engines/buffer/libbuffer.so >> 'src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_engine.c.o' >> 'src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_outbuf.c.o' >> -Wl,--as-needed -shared -fPIC -Wl,--start-group -Wl,-soname,libbuffer.so -g >> -O2 -fdebug-prefix-map=/build/efl-1.22.0-alpha1=. -fstack-protector-strong >> -Wformat -Werror=format-security -fvisibility=hidden -Wl,-z,relro -Wl,-z,now >> -Wl,-z,defs -Wl,--as-needed -lm -ldl src/lib/eina/libeina.so.1.22.0 >> src/lib/eo/libeo.so.1.22.0 src/lib/ector/libector.so.1.22.0 >> src/lib/efl/libefl.so.1.22.0 src/lib/emile/libemile.so.1.22.0 >> src/lib/eet/libeet.so.1.22.0 src/lib/ecore/libecore.so.1.22.0 >> src/static_libs/buildsystem/libbuildsystem.a >> src/wayland_protocol/libwayland_protocol.a -ldl >> /lib/x86_64-linux-gnu/libsystemd.so >> /usr/lib/x86_64-linux-gnu/libunwind-generic.so >> /usr/lib/x86_64-linux-gnu/libunwind.so -ldl -ldl -ldl -ldl -ldl -ldl -ldl >> -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl >> /usr/lib/x86_64-linux-gnu/libfreetype.so >> /usr/lib/x86_64-linux-gnu/libfontconfig.so >> /usr/lib/x86_64-linux-gnu/libfribidi.so >> /usr/lib/x86_64-linux-gnu/libluajit-5.1.so >> /usr/lib/x86_64-linux-gnu/libharfbuzz.so >> /usr/lib/x86_64-linux-gnu/libwayland-client.so -lm -ldl -ldl -Wl,--end-group >> -pthread >> '-Wl,-rpath,$ORIGIN/../../../../lib/eina:$ORIGIN/../../../../lib/eo:$ORIGIN/../../../../lib/ector:$ORIGIN/../../../../lib/ector/software:$ORIGIN/../../../../lib/efl:$ORIGIN/../../../../static_libs/triangulator:$ORIGIN/../../../../static_libs/freetype:$ORIGIN/../../../../static_libs/draw:$ORIGIN/../../../../lib/emile:$ORIGIN/../../../../lib/eet:$ORIGIN/../../../../lib/ecore:$ORIGIN/../../../../static_libs/buildsystem:$ORIGIN/../../../../wayland_protocol' >> >> -Wl,-rpath-link,/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/eina:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/eo:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/ector:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/li >> >>
Re: [E-devel] 1.22 work items list
Hello Ross On 03.03.19 21:49, Ross Vandegrift wrote: > On Thu, Feb 28, 2019 at 05:45:29PM +0100, Stefan Schmidt wrote: >> For packagers I would like to remind that this release will use the >> autotools builds system as official base. Tarballs will be generated >> with. We will also provide meson generated tarballs where we would >> appreciate testing (Simotek already promised to do that on OpenSUSE, >> other are more than welcome). This is especially critically as we will >> remove the autotools build system completely from master after this >> release is out. It will only remain in the efl-1.22 stable branch at >> that point. Don't stay behind and make sure your use cases are covered >> with meson. > > Thanks Stefan. I tested 1.22.0-alpha1 from git with the Debian packaging. > > The build fails on evas modules when linking with -Wl,-z,defs. Example > failure > below. I tried adding evas to the dependencies, but couldn't get it working. > > Disabled strict linking for now just to get through a build. Some questions > about the result: > - evas loaders/savers modules aren't generated. Maybe built static in spite > of > -Devas-modules=shared? > - maybe the same issue with emotion players > - no static libs are generated. Is that intentional. > - shaders aren't regenerated w/EFL_SHD_REGEN. Easy to workaround, but just > want to make sure that's expected. Thanks a lot for taking the time to test the meson setup with Debian. Appreciated. Seems strict linking is something we have not yet tested with our meson build. Good to know. I will see that we have a look at this. regards Stefan Schmidt > Ross > > > > FAILED: src/modules/evas/engines/buffer/libbuffer.so > ccache cc -o src/modules/evas/engines/buffer/libbuffer.so > 'src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_engine.c.o' > 'src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_outbuf.c.o' > -Wl,--as-needed -shared -fPIC -Wl,--start-group -Wl,-soname,libbuffer.so -g > -O2 -fdebug-prefix-map=/build/efl-1.22.0-alpha1=. -fstack-protector-strong > -Wformat -Werror=format-security -fvisibility=hidden -Wl,-z,relro -Wl,-z,now > -Wl,-z,defs -Wl,--as-needed -lm -ldl src/lib/eina/libeina.so.1.22.0 > src/lib/eo/libeo.so.1.22.0 src/lib/ector/libector.so.1.22.0 > src/lib/efl/libefl.so.1.22.0 src/lib/emile/libemile.so.1.22.0 > src/lib/eet/libeet.so.1.22.0 src/lib/ecore/libecore.so.1.22.0 > src/static_libs/buildsystem/libbuildsystem.a > src/wayland_protocol/libwayland_protocol.a -ldl > /lib/x86_64-linux-gnu/libsystemd.so > /usr/lib/x86_64-linux-gnu/libunwind-generic.so > /usr/lib/x86_64-linux-gnu/libunwind.so -ldl -ldl -ldl -ldl -ldl -ldl -ldl > -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl > /usr/lib/x86_64-linux-gnu/libfreetype.so > /usr/lib/x86_64-linux-gnu/libfontconfig.so > /usr/lib/x86_64-linux-gnu/libfribidi.so > /usr/lib/x86_64-linux-gnu/libluajit-5.1.so > /usr/lib/x86_64-linux-gnu/libharfbuzz.so > /usr/lib/x86_64-linux-gnu/libwayland-client.so -lm -ldl -ldl -Wl,--end-group > -pthread > '-Wl,-rpath,$ORIGIN/../../../../lib/eina:$ORIGIN/../../../../lib/eo:$ORIGIN/../../../../lib/ector:$ORIGIN/../../../../lib/ector/software:$ORIGIN/../../../../lib/efl:$ORIGIN/../../../../static_libs/triangulator:$ORIGIN/../../../../static_libs/freetype:$ORIGIN/../../../../static_libs/draw:$ORIGIN/../../../../lib/emile:$ORIGIN/../../../../lib/eet:$ORIGIN/../../../../lib/ecore:$ORIGIN/../../../../static_libs/buildsystem:$ORIGIN/../../../../wayland_protocol' > > -Wl,-rpath-link,/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/eina:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/eo:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/ector:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/li > > b/ector/software:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/efl:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/static_libs/triangulator:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/static_libs/freetype:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/static_libs/draw:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/emile:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/eet:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/ecore:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/static_libs/buildsystem:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/wayland_protocol > /usr/bin/ld: > src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_engine.c.o: in > function `module_open': > ./obj-x86_64-linux-gnu/../src/modules/evas/engines/buffer/evas_engine.c:137: > undefined reference to `_evas_module_engine_inherit' > /usr/bin/ld: > src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_engine.c.o: in > function `evas_render_engine_software_generic_clean': > ./obj-x86_64-linux-gnu/../src/modules/evas/engines/buffer/../software_generic/Evas_Engine_Software_Generic.h:155: > undefined reference to `evas_common_tilebuf_free' > /usr/bin/ld: >
Re: [E-devel] 1.22 work items list
On Thu, Feb 28, 2019 at 05:45:29PM +0100, Stefan Schmidt wrote: > For packagers I would like to remind that this release will use the > autotools builds system as official base. Tarballs will be generated > with. We will also provide meson generated tarballs where we would > appreciate testing (Simotek already promised to do that on OpenSUSE, > other are more than welcome). This is especially critically as we will > remove the autotools build system completely from master after this > release is out. It will only remain in the efl-1.22 stable branch at > that point. Don't stay behind and make sure your use cases are covered > with meson. Thanks Stefan. I tested 1.22.0-alpha1 from git with the Debian packaging. The build fails on evas modules when linking with -Wl,-z,defs. Example failure below. I tried adding evas to the dependencies, but couldn't get it working. Disabled strict linking for now just to get through a build. Some questions about the result: - evas loaders/savers modules aren't generated. Maybe built static in spite of -Devas-modules=shared? - maybe the same issue with emotion players - no static libs are generated. Is that intentional. - shaders aren't regenerated w/EFL_SHD_REGEN. Easy to workaround, but just want to make sure that's expected. Ross FAILED: src/modules/evas/engines/buffer/libbuffer.so ccache cc -o src/modules/evas/engines/buffer/libbuffer.so 'src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_engine.c.o' 'src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_outbuf.c.o' -Wl,--as-needed -shared -fPIC -Wl,--start-group -Wl,-soname,libbuffer.so -g -O2 -fdebug-prefix-map=/build/efl-1.22.0-alpha1=. -fstack-protector-strong -Wformat -Werror=format-security -fvisibility=hidden -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -lm -ldl src/lib/eina/libeina.so.1.22.0 src/lib/eo/libeo.so.1.22.0 src/lib/ector/libector.so.1.22.0 src/lib/efl/libefl.so.1.22.0 src/lib/emile/libemile.so.1.22.0 src/lib/eet/libeet.so.1.22.0 src/lib/ecore/libecore.so.1.22.0 src/static_libs/buildsystem/libbuildsystem.a src/wayland_protocol/libwayland_protocol.a -ldl /lib/x86_64-linux-gnu/libsystemd.so /usr/lib/x86_64-linux-gnu/libunwind-generic.so /usr/lib/x86_64-linux-gnu/libunwind.so -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl -ldl /usr/lib/x86_64-linux-gnu/libfreetype.so /usr/lib/x86_64-linux-gnu/libfontconfig.so /usr/lib/x86_64-linux-gnu/libfribidi.so /usr/lib/x86_64-linux-gnu/libluajit-5.1.so /usr/lib/x86_64-linux-gnu/libharfbuzz.so /usr/lib/x86_64-linux-gnu/libwayland-client.so -lm -ldl -ldl -Wl,--end-group -pthread '-Wl,-rpath,$ORIGIN/../../../../lib/eina:$ORIGIN/../../../../lib/eo:$ORIGIN/../../../../lib/ector:$ORIGIN/../../../../lib/ector/software:$ORIGIN/../../../../lib/efl:$ORIGIN/../../../../static_libs/triangulator:$ORIGIN/../../../../static_libs/freetype:$ORIGIN/../../../../static_libs/draw:$ORIGIN/../../../../lib/emile:$ORIGIN/../../../../lib/eet:$ORIGIN/../../../../lib/ecore:$ORIGIN/../../../../static_libs/buildsystem:$ORIGIN/../../../../wayland_protocol' -Wl,-rpath-link,/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/eina:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/eo:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/ector:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/ector/software:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/efl:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/static_libs/triangulator:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/static_libs/freetype:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/static_libs/draw:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/emile:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/eet:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/lib/ecore:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/static_libs/buildsystem:/build/efl-1.22.0-alpha1/obj-x86_64-linux-gnu/src/wayland_protocol /usr/bin/ld: src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_engine.c.o: in function `module_open': ./obj-x86_64-linux-gnu/../src/modules/evas/engines/buffer/evas_engine.c:137: undefined reference to `_evas_module_engine_inherit' /usr/bin/ld: src/modules/evas/engines/buffer/5576b3e@@buffer@sha/evas_engine.c.o: in function `evas_render_engine_software_generic_clean': ./obj-x86_64-linux-gnu/../src/modules/evas/engines/buffer/../software_generic/Evas_Engine_Software_Generic.h:155: undefined reference to `evas_common_tilebuf_free' /usr/bin/ld: ./obj-x86_64-linux-gnu/../src/modules/evas/engines/buffer/../software_generic/Evas_Engine_Software_Generic.h:158: undefined reference to `evas_common_tilebuf_free_render_rects' /usr/bin/ld: ./obj-x86_64-linux-gnu/../src/modules/evas/engines/buffer/../software_generic/Evas_Engine_Software_Generic.h:159: undefined reference to `evas_common_tilebuf_free_render_rects' /usr/bin/ld:
Re: [E-devel] 1.22 work items list
Hello. On 28.02.19 17:45, Stefan Schmidt wrote: > > 2) Running Coverity to have some additional static analysis on the code > to see if it finds any critical issues we should fix before the release. I submitted a build from the alpha1 tag and it got analyzed over night. In total we have 103 outstanding issues, with 31 marked as high. Resource leaks, memory corruptions, etc. These are the ones we should pay attention to before the release. If more of them getting fixed, even better. Have a look and help out to get them fixed. https://scan6.coverity.com/reports.htm#v17028/p10304 regards Stefan Schmidt ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
