Re: [e-users] enlightenment desktop fails after NVIDIA update

2016-10-10 Thread The Rasterman 
On Mon, 10 Oct 2016 19:56:44 -0300 Gustavo Sverzut Barbieri
 said:

> Raster,
> 
> Maybe it was a corrupted file?

a corrupted file should entirely fail to load. the entires are compressed so if
the compressed data got an error the decompress would fail thus load fail. only
if it was corrupted in some way that magically kept it a valid decompressable
chunk and thus decompressed "funny"...

0it could be the data corrupted in ram before compression. when we read back
the shader binaries they were messed up... but we have no way of knowing that.
i find it unlikely they'd be corrupted by other code as when we compile
shaders, we then save them all pretty much immediately and they dont have time
to get messed up really by other code/threads... hmmm.

we do rely on the filesystem to not go magically corrupt files. we could crc
check etc. etc. but this shouldnt be necessary unless the kernel, filesystem,
ram, cpu or actual media don't have serious low-level issues (bits flipping in
ram after compress or cpu literally dropping data on copying/moving around, in
which case there are major hardware problems on the system). if there are
kernel bugs (in fs code or other related code) then thats pretty nasty.

> Maybe use EET features to verify that by signing or compressing or
> even some checksum?

yeah - though this will add overhead if we do this on every load. i kind of
considered there to already be enough safeguards like the decompression and the
fs/kernel etc. taking care of this... :/ we do have eet file signing but it
does require a proper certificate to do it with. we could just have a crc32
checksum somewhere and have a tool be able to sanity check he eet file if
requested...

> On Mon, Oct 10, 2016 at 7:43 PM, Carsten Haitzler 
> wrote:
> > On Mon, 10 Oct 2016 12:30:31 -0700 Eric  said:
> >
> >> On 10/10/2016 08:42 AM, Carsten Haitzler (The Rasterman) wrote:
> >> > On Sun, 9 Oct 2016 17:58:05 -0700 Eric  said:
> >> >
> >> >> On 10/09/2016 04:22 PM, Carsten Haitzler (The Rasterman) wrote:
> >> >>> On Sun, 9 Oct 2016 13:24:34 -0700 Eric  said:
> >> >>>
> >>  On 10/08/2016 05:06 PM, Carsten Haitzler (The Rasterman) wrote:
> >> > On Sat, 8 Oct 2016 09:59:27 -0700 Eric  said:
> >> >
> >> >> On 10/08/2016 02:33 AM, Simon Lees wrote:
> >> >>>
> >> >>>
> >> >>> On 10/08/2016 06:25 PM, Eric wrote:
> >> >>
> >> >
> >> 
> >>  Thank you Simon,
> >> 
> >>  I was able to get it working using the repository.  I did find out
> >>  that the problem was with the new NVIDIA driver that I have to
> >>  choose software rendering instead of OpenGL.  With OpenGL I just
> >>  get the mouse cursor icon displaying with nothing else.  Using
> >>  software rendering makes my desktop a little sluggish on this
> >>  machine.
> >> 
> >>  I am going to see if I can role back the NVIDIA update somehow.
> >>  My google search has not led me with the right info on how to do
> >>  that yet on openSUSE.
> >> 
> >>  Eric Meddleton
> >> 
> >> >>>
> >> >>> Updates should remain available, so if you go to yast search for
> >> >>> NVIDIA in the software manager, there should be a version tab that
> >> >>> you can use to roll back.
> >> >>>
> >> >>>
> >> >>
> >> >> Unfortunately, the previous version for NVIDIA is not available in
> >> >> yast, just the version I have installed and the i586 version.  (But
> >> >> that is getting into openSUSE territory and not really applicable to
> >> >> e-users discussion.)
> >> >>
> >> >> Now that I remember, I had a similar situation on a different
> >> >> machine with Arch linux a year or so ago.  That machine had a
> >> >> NVIDIA GeForce GTX570 card.  I have just lived with the software
> >> >> rendering on that machine without any noticeable difference maybe
> >> >> due to it having an intel i7 processor.  No updates on NVIDIA or
> >> >> enlightenment and the ELF libraries  has helped  since then and the
> >> >> downgrade would have meant also downgrading the kernel so I just
> >> >> let it go.  It may just need to be re-installed to get it all
> >> >> sorted out and I just have not wanted to try that yet. :-)
> >> >>
> >> >> The machine in question now only has an AMD Athlon(tm) 64 X2 Dual
> >> >> Core Processor 5600+ and is getting a little old.  I will try
> >> >> updating openSUSE to the next version to see how that goes.
> >> >>
> >> >> Thank you very much for your help.
> >> >
> >> > hmmm i wonder if it's the shader cache? try
> >> >
> >> > rm -rf ~/.cache/evas*
> >> >
> >> >
> >> 
> >>  Wow,
> >> 
> >>  This was what was wrong with my Arch linux install all along.  I
> >>  deleted

Re: [e-users] enlightenment desktop fails after NVIDIA update

2016-10-10 Thread Gustavo Sverzut Barbieri 
Raster,

Maybe it was a corrupted file?

Maybe use EET features to verify that by signing or compressing or
even some checksum?

On Mon, Oct 10, 2016 at 7:43 PM, Carsten Haitzler  wrote:
> On Mon, 10 Oct 2016 12:30:31 -0700 Eric  said:
>
>> On 10/10/2016 08:42 AM, Carsten Haitzler (The Rasterman) wrote:
>> > On Sun, 9 Oct 2016 17:58:05 -0700 Eric  said:
>> >
>> >> On 10/09/2016 04:22 PM, Carsten Haitzler (The Rasterman) wrote:
>> >>> On Sun, 9 Oct 2016 13:24:34 -0700 Eric  said:
>> >>>
>>  On 10/08/2016 05:06 PM, Carsten Haitzler (The Rasterman) wrote:
>> > On Sat, 8 Oct 2016 09:59:27 -0700 Eric  said:
>> >
>> >> On 10/08/2016 02:33 AM, Simon Lees wrote:
>> >>>
>> >>>
>> >>> On 10/08/2016 06:25 PM, Eric wrote:
>> >>
>> >
>> 
>>  Thank you Simon,
>> 
>>  I was able to get it working using the repository.  I did find out
>>  that the problem was with the new NVIDIA driver that I have to 
>>  choose
>>  software rendering instead of OpenGL.  With OpenGL I just get the
>>  mouse cursor icon displaying with nothing else.  Using software
>>  rendering makes my desktop a little sluggish on this machine.
>> 
>>  I am going to see if I can role back the NVIDIA update somehow.  My
>>  google search has not led me with the right info on how to do that
>>  yet on openSUSE.
>> 
>>  Eric Meddleton
>> 
>> >>>
>> >>> Updates should remain available, so if you go to yast search for
>> >>> NVIDIA in the software manager, there should be a version tab that
>> >>> you can use to roll back.
>> >>>
>> >>>
>> >>
>> >> Unfortunately, the previous version for NVIDIA is not available in
>> >> yast, just the version I have installed and the i586 version.  (But
>> >> that is getting into openSUSE territory and not really applicable to
>> >> e-users discussion.)
>> >>
>> >> Now that I remember, I had a similar situation on a different machine
>> >> with Arch linux a year or so ago.  That machine had a NVIDIA GeForce
>> >> GTX570 card.  I have just lived with the software rendering on that
>> >> machine without any noticeable difference maybe due to it having an
>> >> intel i7 processor.  No updates on NVIDIA or enlightenment and the ELF
>> >> libraries  has helped  since then and the downgrade would have meant
>> >> also downgrading the kernel so I just let it go.  It may just need to
>> >> be re-installed to get it all sorted out and I just have not wanted to
>> >> try that yet. :-)
>> >>
>> >> The machine in question now only has an AMD Athlon(tm) 64 X2 Dual Core
>> >> Processor 5600+ and is getting a little old.  I will try updating
>> >> openSUSE to the next version to see how that goes.
>> >>
>> >> Thank you very much for your help.
>> >
>> > hmmm i wonder if it's the shader cache? try
>> >
>> > rm -rf ~/.cache/evas*
>> >
>> >
>> 
>>  Wow,
>> 
>>  This was what was wrong with my Arch linux install all along.  I deleted
>>  the .cache files and now I have openGL working again on that system.
>> 
>>  Thank you very much,
>> 
>>  Eric Meddleton
>> >>>
>> >>> interesting. what gpu/driver? we use the string info from the gl driver
>> >>> (vendor, renderer and version), and this should lead to a different file
>> >>> in in the cache directory if these strings change. also we use the efl
>> >>> version there too. so any upgrade of efl will result in a new shader
>> >>> cache being generated as will any change from the driver. we kind of
>> >>> expect the gl driver to change its renderer/vendor/version strings should
>> >>> anything change in the driver that would affect the binary shaders we
>> >>> cache. if the driver doesn't do this i'd be inclined to file a bug report
>> >>> with the driver author/maintainer as i really don't know of another
>> >>> mechanism to know that the cached binary shaders are still usable. the
>> >>> efl version changes because we may change shaders between versions (the
>> >>> source) so this should handle that. the only case that will possibly be
>> >>> an issue is "during development" when we are working on git master
>> >>> - if a shader changes indeed our version will not have changed and you
>> >>> want to nuke the shader cache manually. this is only relevant for
>> >>> developers or those tracking git master. we are geared to producing a
>> >>> clean release so things can be a bit dirty during development.
>> >>>
>> >>> for example here are some of the files in 2 of my shader caches locally:
>> >>>
>> >>>  8:13AM ~ > ls ~/.cache/evas_gl_common_caches
>> >>> total 24K
>> >>> 4.0K 'NVIDIA Corporation::4.5.0 NVIDIA 367.35::GeForce GTX
>> >>> 970PCIeSSE2::v-1.18.0::binary_shader.eet' 4.0K

Re: [e-users] enlightenment desktop fails after NVIDIA update

2016-10-10 Thread The Rasterman 
On Mon, 10 Oct 2016 12:30:31 -0700 Eric  said:

> On 10/10/2016 08:42 AM, Carsten Haitzler (The Rasterman) wrote:
> > On Sun, 9 Oct 2016 17:58:05 -0700 Eric  said:
> >
> >> On 10/09/2016 04:22 PM, Carsten Haitzler (The Rasterman) wrote:
> >>> On Sun, 9 Oct 2016 13:24:34 -0700 Eric  said:
> >>>
>  On 10/08/2016 05:06 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Sat, 8 Oct 2016 09:59:27 -0700 Eric  said:
> >
> >> On 10/08/2016 02:33 AM, Simon Lees wrote:
> >>>
> >>>
> >>> On 10/08/2016 06:25 PM, Eric wrote:
> >>
> >
> 
>  Thank you Simon,
> 
>  I was able to get it working using the repository.  I did find out
>  that the problem was with the new NVIDIA driver that I have to choose
>  software rendering instead of OpenGL.  With OpenGL I just get the
>  mouse cursor icon displaying with nothing else.  Using software
>  rendering makes my desktop a little sluggish on this machine.
> 
>  I am going to see if I can role back the NVIDIA update somehow.  My
>  google search has not led me with the right info on how to do that
>  yet on openSUSE.
> 
>  Eric Meddleton
> 
> >>>
> >>> Updates should remain available, so if you go to yast search for
> >>> NVIDIA in the software manager, there should be a version tab that
> >>> you can use to roll back.
> >>>
> >>>
> >>
> >> Unfortunately, the previous version for NVIDIA is not available in
> >> yast, just the version I have installed and the i586 version.  (But
> >> that is getting into openSUSE territory and not really applicable to
> >> e-users discussion.)
> >>
> >> Now that I remember, I had a similar situation on a different machine
> >> with Arch linux a year or so ago.  That machine had a NVIDIA GeForce
> >> GTX570 card.  I have just lived with the software rendering on that
> >> machine without any noticeable difference maybe due to it having an
> >> intel i7 processor.  No updates on NVIDIA or enlightenment and the ELF
> >> libraries  has helped  since then and the downgrade would have meant
> >> also downgrading the kernel so I just let it go.  It may just need to
> >> be re-installed to get it all sorted out and I just have not wanted to
> >> try that yet. :-)
> >>
> >> The machine in question now only has an AMD Athlon(tm) 64 X2 Dual Core
> >> Processor 5600+ and is getting a little old.  I will try updating
> >> openSUSE to the next version to see how that goes.
> >>
> >> Thank you very much for your help.
> >
> > hmmm i wonder if it's the shader cache? try
> >
> > rm -rf ~/.cache/evas*
> >
> >
> 
>  Wow,
> 
>  This was what was wrong with my Arch linux install all along.  I deleted
>  the .cache files and now I have openGL working again on that system.
> 
>  Thank you very much,
> 
>  Eric Meddleton
> >>>
> >>> interesting. what gpu/driver? we use the string info from the gl driver
> >>> (vendor, renderer and version), and this should lead to a different file
> >>> in in the cache directory if these strings change. also we use the efl
> >>> version there too. so any upgrade of efl will result in a new shader
> >>> cache being generated as will any change from the driver. we kind of
> >>> expect the gl driver to change its renderer/vendor/version strings should
> >>> anything change in the driver that would affect the binary shaders we
> >>> cache. if the driver doesn't do this i'd be inclined to file a bug report
> >>> with the driver author/maintainer as i really don't know of another
> >>> mechanism to know that the cached binary shaders are still usable. the
> >>> efl version changes because we may change shaders between versions (the
> >>> source) so this should handle that. the only case that will possibly be
> >>> an issue is "during development" when we are working on git master
> >>> - if a shader changes indeed our version will not have changed and you
> >>> want to nuke the shader cache manually. this is only relevant for
> >>> developers or those tracking git master. we are geared to producing a
> >>> clean release so things can be a bit dirty during development.
> >>>
> >>> for example here are some of the files in 2 of my shader caches locally:
> >>>
> >>>  8:13AM ~ > ls ~/.cache/evas_gl_common_caches
> >>> total 24K
> >>> 4.0K 'NVIDIA Corporation::4.5.0 NVIDIA 367.35::GeForce GTX
> >>> 970PCIeSSE2::v-1.18.0::binary_shader.eet' 4.0K 'NVIDIA Corporation::4.5.0
> >>> NVIDIA 367.35::GeForce GTX 970PCIeSSE2::v-1.18.0::surface_cap.eet' 4.0K
> >>> 'NVIDIA Corporation::4.5.0 NVIDIA 367.35::GeForce GTX
> >>> 970PCIeSSE2::v-1.18.99::binary_shader.eet' 4.0K 'NVIDIA Corporation::4.5.0
> >>> NVIDIA 367.35::GeForce GTX 970PCIeSSE2::v-1.18.99::surface_cap.eet' 4.0K

Re: [e-users] enlightenment desktop fails after NVIDIA update

2016-10-10 Thread Eric 
On 10/10/2016 08:42 AM, Carsten Haitzler (The Rasterman) wrote:
> On Sun, 9 Oct 2016 17:58:05 -0700 Eric  said:
>
>> On 10/09/2016 04:22 PM, Carsten Haitzler (The Rasterman) wrote:
>>> On Sun, 9 Oct 2016 13:24:34 -0700 Eric  said:
>>>
 On 10/08/2016 05:06 PM, Carsten Haitzler (The Rasterman) wrote:
> On Sat, 8 Oct 2016 09:59:27 -0700 Eric  said:
>
>> On 10/08/2016 02:33 AM, Simon Lees wrote:
>>>
>>>
>>> On 10/08/2016 06:25 PM, Eric wrote:
>>
>

 Thank you Simon,

 I was able to get it working using the repository.  I did find out that
 the problem was with the new NVIDIA driver that I have to choose
 software rendering instead of OpenGL.  With OpenGL I just get the mouse
 cursor icon displaying with nothing else.  Using software rendering
 makes my desktop a little sluggish on this machine.

 I am going to see if I can role back the NVIDIA update somehow.  My
 google search has not led me with the right info on how to do that yet
 on openSUSE.

 Eric Meddleton

>>>
>>> Updates should remain available, so if you go to yast search for NVIDIA
>>> in the software manager, there should be a version tab that you can use
>>> to roll back.
>>>
>>>
>>
>> Unfortunately, the previous version for NVIDIA is not available in yast,
>> just the version I have installed and the i586 version.  (But that is
>> getting into openSUSE territory and not really applicable to e-users
>> discussion.)
>>
>> Now that I remember, I had a similar situation on a different machine
>> with Arch linux a year or so ago.  That machine had a NVIDIA GeForce
>> GTX570 card.  I have just lived with the software rendering on that
>> machine without any noticeable difference maybe due to it having an
>> intel i7 processor.  No updates on NVIDIA or enlightenment and the ELF
>> libraries  has helped  since then and the downgrade would have meant
>> also downgrading the kernel so I just let it go.  It may just need to be
>> re-installed to get it all sorted out and I just have not wanted to try
>> that yet. :-)
>>
>> The machine in question now only has an AMD Athlon(tm) 64 X2 Dual Core
>> Processor 5600+ and is getting a little old.  I will try updating
>> openSUSE to the next version to see how that goes.
>>
>> Thank you very much for your help.
>
> hmmm i wonder if it's the shader cache? try
>
> rm -rf ~/.cache/evas*
>
>

 Wow,

 This was what was wrong with my Arch linux install all along.  I deleted
 the .cache files and now I have openGL working again on that system.

 Thank you very much,

 Eric Meddleton
>>>
>>> interesting. what gpu/driver? we use the string info from the gl driver
>>> (vendor, renderer and version), and this should lead to a different file in
>>> in the cache directory if these strings change. also we use the efl version
>>> there too. so any upgrade of efl will result in a new shader cache being
>>> generated as will any change from the driver. we kind of expect the gl
>>> driver to change its renderer/vendor/version strings should anything change
>>> in the driver that would affect the binary shaders we cache. if the driver
>>> doesn't do this i'd be inclined to file a bug report with the driver
>>> author/maintainer as i really don't know of another mechanism to know that
>>> the cached binary shaders are still usable. the efl version changes because
>>> we may change shaders between versions (the source) so this should handle
>>> that. the only case that will possibly be an issue is "during development"
>>> when we are working on git master
>>> - if a shader changes indeed our version will not have changed and you want
>>> to nuke the shader cache manually. this is only relevant for developers or
>>> those tracking git master. we are geared to producing a clean release so
>>> things can be a bit dirty during development.
>>>
>>> for example here are some of the files in 2 of my shader caches locally:
>>>
>>>  8:13AM ~ > ls ~/.cache/evas_gl_common_caches
>>> total 24K
>>> 4.0K 'NVIDIA Corporation::4.5.0 NVIDIA 367.35::GeForce GTX
>>> 970PCIeSSE2::v-1.18.0::binary_shader.eet' 4.0K 'NVIDIA Corporation::4.5.0
>>> NVIDIA 367.35::GeForce GTX 970PCIeSSE2::v-1.18.0::surface_cap.eet' 4.0K
>>> 'NVIDIA Corporation::4.5.0 NVIDIA 367.35::GeForce GTX
>>> 970PCIeSSE2::v-1.18.99::binary_shader.eet' 4.0K 'NVIDIA Corporation::4.5.0
>>> NVIDIA 367.35::GeForce GTX 970PCIeSSE2::v-1.18.99::surface_cap.eet' 4.0K
>>> 'NVIDIA Corporation::4.5.0 NVIDIA 370.28::GeForce GTX
>>> 970PCIeSSE2::v-1.18.99::binary_shader.eet' 4.0K 'NVIDIA Corporation::4.5.0
>>> NVIDIA 370.28::GeForce GTX 970PCIeSSE2::v-1.18.99::surface_cap.eet'
>>>
>>> @  8:20AM ~ > ls ~/.cache/evas_gl_common_caches

Re: [e-users] Help trying to compile efl-1.18.1

2016-10-10 Thread The Rasterman 
On Sun, 9 Oct 2016 19:52:50 -0700 Eric  said:

> On 10/09/2016 07:27 PM, Eric wrote:
> > On 10/09/2016 07:06 PM, Eric wrote:
> >> On 10/09/2016 05:56 PM, Carsten Haitzler (The Rasterman) wrote:
> >>> On Sun, 9 Oct 2016 17:38:01 -0700 Eric  said:
> >>>
>  Hello,
> 
>  Sorry for the dumb questions.  I decided to try and compile frm source.
>  I removed all my previous enlightenment files and am compiling from an
>  xfce desktop.
> 
>  I installed all the prerequisite files from enlightenment.org and
>  followed the advice on setting up the build environment.
> 
>  in efl the ./configure goes fine.  When I type make I get the following
>  error:
> 
>  /usr/bin/sed: can't read source/efl-1.18.1/src/lib/eina/libeina.la: No
>  such file or directory
>  libtool:   error: 'source/efl-1.18.1/src/lib/eina/libeina.la' is not a
>  valid libtool archive
> 
>  The compiling stops after it gets to
> 
>  "CCLD lib/eolian/libeolian.la"
> 
>  That file says inside that it depends on
> 
>  dependency_libs=' source/efl-1.18.1/src/lib/eina/libeina.la
>  /home/suse/Downloads/enlightenment -lm -ldl -lrt -lpthread'
> 
>  which mentions the file in the libtool error.  Also I don't know where
>  the /home/suse/Downloads/enlightenment came from in that line.  I am
>  compiling from the directory /home/suse/Downloads/"enlightenment
>  source"/efl-1.18.1 directory.
> 
>  Not sure where to go from here.
> 
>  Thank you for any help.
> 
>  Eric Meddleton
> >>>
> >>> you used the tarball you downloaded from enlightenment.org?
> >>>
> >>>
> >>
> >> Yes, but I will download it and try again and let you know how it goes.
> >> Now that you ask, I remember a few years ago when I was trying to
> >> compile and you came to the conclusion that my download was corrupted
> >> based on the error I was getting.
> >>
> >
> > A fresh download ends up with the same error message.
> 
> OK,
> 
> I am officially incompetant.  I was compiling in a directory with a 
> space in the name "enlighenment source" which was the cause of the error.
> 
> I may have questions later trying to get this installed but it is 
> compiling correctly now.
> 
> Eric Meddleton

i just realized that too on your previous mail... yeah. we have to generate
paths and well... autoconf doesnt always escape things for us when generating
as -I or -L include lines and so on, so having a space in the path above the
src can cause real issues as we have to create commandlines like

gcc $PATH0/x.c -I$PATH1 -L$PATH2 -o $PATH3/xxx

so $PATH1-3 have 5to be full paths and if a spacve is in there.. it becomes
multilpe args. these are replaced at completely different times like

${top_srcdir} means the top src dir and spaces may not be accounted for when
doing this and we cant change this variable in our makefile.am's so this may
cause issues. i'm not sure there is a "sane solution" to this other than "dnt
use spaces in your dirnames" where you build code :) it's very likel you'll
find lots and lots of srcs of software that have build issues in such dirs.
just as an example: harfbuzz has exactly this same issue if i add a space:

/bin/sh ../../libtool  --tag=CC   --mode=link ccache gcc  -Ofast -march=native
-g -pipe -fvisibility=hidden -ffast-math -Wno-unused-but-set-parameter
-Wno-clobbered -W -Wall -Wextra  -Bsymbolic-functions -o test-unicode
test_unicode-test-unicode.o ../../src/libharfbuzz.la
-lglib-2.0 ../../src/libharfbuzz-icu.la -licuuc -licudata libtool:   error:
cannot find the library 'buzz/src/libharfbuzz.la' or unhandled argument
'buzz/src/libharfbuzz.la'
...
12:49AM ~/C/other/harf buzz > pwd
/home/raster/C/other/harf buzz

:) i am sure i can fund mountains of sw that will not like this. :)

-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (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-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] Help trying to compile efl-1.18.1

2016-10-10 Thread The Rasterman 
On Sun, 9 Oct 2016 19:06:22 -0700 Eric  said:

> On 10/09/2016 05:56 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Sun, 9 Oct 2016 17:38:01 -0700 Eric  said:
> >
> >> Hello,
> >>
> >> Sorry for the dumb questions.  I decided to try and compile frm source.
> >> I removed all my previous enlightenment files and am compiling from an
> >> xfce desktop.
> >>
> >> I installed all the prerequisite files from enlightenment.org and
> >> followed the advice on setting up the build environment.
> >>
> >> in efl the ./configure goes fine.  When I type make I get the following
> >> error:
> >>
> >> /usr/bin/sed: can't read source/efl-1.18.1/src/lib/eina/libeina.la: No
> >> such file or directory
> >> libtool:   error: 'source/efl-1.18.1/src/lib/eina/libeina.la' is not a
> >> valid libtool archive
> >>
> >> The compiling stops after it gets to
> >>
> >> "CCLD lib/eolian/libeolian.la"
> >>
> >> That file says inside that it depends on
> >>
> >> dependency_libs=' source/efl-1.18.1/src/lib/eina/libeina.la
> >> /home/suse/Downloads/enlightenment -lm -ldl -lrt -lpthread'
> >>
> >> which mentions the file in the libtool error.  Also I don't know where
> >> the /home/suse/Downloads/enlightenment came from in that line.  I am
> >> compiling from the directory /home/suse/Downloads/"enlightenment
> >> source"/efl-1.18.1 directory.
> >>
> >> Not sure where to go from here.
> >>
> >> Thank you for any help.
> >>
> >> Eric Meddleton
> >
> > you used the tarball you downloaded from enlightenment.org?
> >
> >
> 
> Yes, but I will download it and try again and let you know how it goes. 
> Now that you ask, I remember a few years ago when I was trying to 
> compile and you came to the conclusion that my download was corrupted 
> based on the error I was getting.
> 
> Eric Meddleton

oooh wait wait you have a SPACE in your directory name? "enlightenment
source" ? /home/suse is your homedir?


-- 
- Codito, ergo sum - "I code, therefore I am" --
The Rasterman (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-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users

Re: [e-users] enlightenment desktop fails after NVIDIA update

2016-10-10 Thread The Rasterman 
On Sun, 9 Oct 2016 17:58:05 -0700 Eric  said:

> On 10/09/2016 04:22 PM, Carsten Haitzler (The Rasterman) wrote:
> > On Sun, 9 Oct 2016 13:24:34 -0700 Eric  said:
> >
> >> On 10/08/2016 05:06 PM, Carsten Haitzler (The Rasterman) wrote:
> >>> On Sat, 8 Oct 2016 09:59:27 -0700 Eric  said:
> >>>
>  On 10/08/2016 02:33 AM, Simon Lees wrote:
> >
> >
> > On 10/08/2016 06:25 PM, Eric wrote:
> 
> >>>
> >>
> >> Thank you Simon,
> >>
> >> I was able to get it working using the repository.  I did find out that
> >> the problem was with the new NVIDIA driver that I have to choose
> >> software rendering instead of OpenGL.  With OpenGL I just get the mouse
> >> cursor icon displaying with nothing else.  Using software rendering
> >> makes my desktop a little sluggish on this machine.
> >>
> >> I am going to see if I can role back the NVIDIA update somehow.  My
> >> google search has not led me with the right info on how to do that yet
> >> on openSUSE.
> >>
> >> Eric Meddleton
> >>
> >
> > Updates should remain available, so if you go to yast search for NVIDIA
> > in the software manager, there should be a version tab that you can use
> > to roll back.
> >
> >
> 
>  Unfortunately, the previous version for NVIDIA is not available in yast,
>  just the version I have installed and the i586 version.  (But that is
>  getting into openSUSE territory and not really applicable to e-users
>  discussion.)
> 
>  Now that I remember, I had a similar situation on a different machine
>  with Arch linux a year or so ago.  That machine had a NVIDIA GeForce
>  GTX570 card.  I have just lived with the software rendering on that
>  machine without any noticeable difference maybe due to it having an
>  intel i7 processor.  No updates on NVIDIA or enlightenment and the ELF
>  libraries  has helped  since then and the downgrade would have meant
>  also downgrading the kernel so I just let it go.  It may just need to be
>  re-installed to get it all sorted out and I just have not wanted to try
>  that yet. :-)
> 
>  The machine in question now only has an AMD Athlon(tm) 64 X2 Dual Core
>  Processor 5600+ and is getting a little old.  I will try updating
>  openSUSE to the next version to see how that goes.
> 
>  Thank you very much for your help.
> >>>
> >>> hmmm i wonder if it's the shader cache? try
> >>>
> >>> rm -rf ~/.cache/evas*
> >>>
> >>>
> >>
> >> Wow,
> >>
> >> This was what was wrong with my Arch linux install all along.  I deleted
> >> the .cache files and now I have openGL working again on that system.
> >>
> >> Thank you very much,
> >>
> >> Eric Meddleton
> >
> > interesting. what gpu/driver? we use the string info from the gl driver
> > (vendor, renderer and version), and this should lead to a different file in
> > in the cache directory if these strings change. also we use the efl version
> > there too. so any upgrade of efl will result in a new shader cache being
> > generated as will any change from the driver. we kind of expect the gl
> > driver to change its renderer/vendor/version strings should anything change
> > in the driver that would affect the binary shaders we cache. if the driver
> > doesn't do this i'd be inclined to file a bug report with the driver
> > author/maintainer as i really don't know of another mechanism to know that
> > the cached binary shaders are still usable. the efl version changes because
> > we may change shaders between versions (the source) so this should handle
> > that. the only case that will possibly be an issue is "during development"
> > when we are working on git master
> > - if a shader changes indeed our version will not have changed and you want
> > to nuke the shader cache manually. this is only relevant for developers or
> > those tracking git master. we are geared to producing a clean release so
> > things can be a bit dirty during development.
> >
> > for example here are some of the files in 2 of my shader caches locally:
> >
> >  8:13AM ~ > ls ~/.cache/evas_gl_common_caches
> > total 24K
> > 4.0K 'NVIDIA Corporation::4.5.0 NVIDIA 367.35::GeForce GTX
> > 970PCIeSSE2::v-1.18.0::binary_shader.eet' 4.0K 'NVIDIA Corporation::4.5.0
> > NVIDIA 367.35::GeForce GTX 970PCIeSSE2::v-1.18.0::surface_cap.eet' 4.0K
> > 'NVIDIA Corporation::4.5.0 NVIDIA 367.35::GeForce GTX
> > 970PCIeSSE2::v-1.18.99::binary_shader.eet' 4.0K 'NVIDIA Corporation::4.5.0
> > NVIDIA 367.35::GeForce GTX 970PCIeSSE2::v-1.18.99::surface_cap.eet' 4.0K
> > 'NVIDIA Corporation::4.5.0 NVIDIA 370.28::GeForce GTX
> > 970PCIeSSE2::v-1.18.99::binary_shader.eet' 4.0K 'NVIDIA Corporation::4.5.0
> > NVIDIA 370.28::GeForce GTX 970PCIeSSE2::v-1.18.99::surface_cap.eet'
> >
> > @  8:20AM ~ > ls ~/.cache/evas_gl_common_caches
> >
> > total 52K
> > 4.0K 'Intel Open Source Technology Center::3.0