Re: new dependency for libtizcore required for mesa?

2018-06-07 Thread Dennis Clarke 

On 6/7/18 11:47 AM, Braiam Peguero wrote:



On Thu, Jun 7, 2018 at 11:06 AM, Dennis Clarke > wrote:


On 6/7/18 10:44 AM, Michal Srb wrote:

On čtvrtek 7. června 2018 16:15:50 CEST Dennis Clarke wrote:

Package libtizcore was not found in the pkg-config search path.
Perhaps you should add the directory containing `libtizcore.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libtizcore' found


This is not a problem. It seems to be optional requirement. I
see the same
message in my build log.

checking for RADEON... yes
checking for RADEON... yes
configure: error: LLVM 3.9.0 or newer is required for r600


This is a problem. As it says, you need LLVM >= 3.9.0 and it did
not find one.


Ah .. oops. Thanks for the reply and I should look closer before jumping
  on the "what?" button.

How very odd :

root@xorg:~# apt-get install llvm
Reading package lists... Done
Building dependency tree
Reading state information... Done
llvm is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
root@xorg:~#

Yet my old build process fails looking for LLVM?

The funky Tizonia's OpenMAX IL Core thing isn't required and isn't even
in the debian package list for that matter. Fine. However llvm is
definately installed and has been for a long while.  I am just doing the
usual per the instructions at :

Testing X servers from git
http://who-t.blogspot.com/2012/05/testing-x-servers-from-git.html


That has worked since about 2013 however it has been a while since I
tried. Something odd here ... not sure what it is yet.

Dennis


___
xorg@lists.x.org : X.Org support
Archives: http://lists.freedesktop.org/archives/xorg

Info: https://lists.x.org/mailman/listinfo/xorg

Your subscription address: %(user_address)s


Have you checked that the version installed of llvm is >= 3.9.0?
Debian Stretch by default install 3.8, while you can have 3.9 if
you install the llvm-toolchain-3.9 package. That should be enough.



The issue is definately version.
This is an older debian 8 system and thus  :

root@xorg:~# apt-get install llvm-3.5 llvm-3.5-dev llvm-3.5-runtime 
llvm-3.5-examples llvm-3.5-doc llvm-3.5-tools

Reading package lists... Done
Building dependency tree
Reading state information... Done
llvm-3.5 is already the newest version.
llvm-3.5 set to manually installed.
llvm-3.5-dev is already the newest version.
llvm-3.5-dev set to manually installed.
llvm-3.5-runtime is already the newest version.
llvm-3.5-runtime set to manually installed.
The following extra packages will be installed:
  libjs-underscore
The following NEW packages will be installed:
  libjs-underscore llvm-3.5-doc llvm-3.5-examples llvm-3.5-tools
0 upgraded, 4 newly installed, 0 to remove and 5 not upgraded.
Need to get 1,847 kB of archives.
After this operation, 10.6 MB of additional disk space will be used.
Do you want to continue? [Y/n]
Get:1 http://ftp.ca.debian.org/debian/ jessie/main libjs-underscore all 
1.7.0~dfsg-1 [49.9 kB]
Get:2 http://ftp.ca.debian.org/debian/ jessie/main llvm-3.5-doc all 
1:3.5-10 [1,461 kB]
Get:3 http://ftp.ca.debian.org/debian/ jessie/main llvm-3.5-examples all 
1:3.5-10 [181 kB]
Get:4 http://ftp.ca.debian.org/debian/ jessie/main llvm-3.5-tools amd64 
1:3.5-10 [154 kB]

Fetched 1,847 kB in 3s (598 kB/s)
Selecting previously unselected package libjs-underscore.
(Reading database ... 155535 files and directories currently installed.)
Preparing to unpack .../libjs-underscore_1.7.0~dfsg-1_all.deb ...
Unpacking libjs-underscore (1.7.0~dfsg-1) ...
Selecting previously unselected package llvm-3.5-doc.
Preparing to unpack .../llvm-3.5-doc_1%3a3.5-10_all.deb ...
Unpacking llvm-3.5-doc (1:3.5-10) ...
Selecting previously unselected package llvm-3.5-examples.
Preparing to unpack .../llvm-3.5-examples_1%3a3.5-10_all.deb ...
Unpacking llvm-3.5-examples (1:3.5-10) ...
Selecting previously unselected package llvm-3.5-tools.
Preparing to unpack .../llvm-3.5-tools_1%3a3.5-10_amd64.deb ...
Unpacking llvm-3.5-tools (1:3.5-10) ...
Setting up libjs-underscore (1.7.0~dfsg-1) ...
Setting up llvm-3.5-doc (1:3.5-10) ...
Setting up llvm-3.5-examples (1:3.5-10) ...
Setting up llvm-3.5-tools (1:3.5-10) ...
root@xorg:~# exit
logout
xorg $
xorg $ ./util/modular/build.sh --clone --autoresume built.modules /opt/xorg
Building to run Linux / x86_64 ()
Thu Jun  7 16:27:03 GMT 2018
Skipping util/macros...
Skipping font/util...
Skipping doc/xorg-sgml-doctools...
Skipping doc/xorg-docs...
Skipping proto/xorgproto...
Skipping

Re: new dependency for libtizcore required for mesa?

2018-06-07 Thread Brad Rogers 
On Thu, 7 Jun 2018 11:06:30 -0400
Dennis Clarke  wrote:

Hello Dennis,

>That has worked since about 2013 however it has been a while since I 
>tried. Something odd here ... not sure what it is yet.

I'm no programmer/compiling guru, but;

Missing the correct -dev package, perhaps?  Bearing in mind Debian has
multiple versions of LLVM available (3.9 to 6.0, IIRC) having the right
-dev package may be significant.

-- 
 Regards  _
 / )   "The blindingly obvious is
/ _)radnever immediately apparent"
My limbs are like palm trees swaying in the breeze
Mirage - Siouxsie & The Banshees


pgpHRQYS5MpE3.pgp
Description: OpenPGP digital signature
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: new dependency for libtizcore required for mesa?

2018-06-07 Thread Braiam Peguero 
On Thu, Jun 7, 2018 at 11:06 AM, Dennis Clarke 
wrote:

> On 6/7/18 10:44 AM, Michal Srb wrote:
>
>> On čtvrtek 7. června 2018 16:15:50 CEST Dennis Clarke wrote:
>>
>>> Package libtizcore was not found in the pkg-config search path.
>>> Perhaps you should add the directory containing `libtizcore.pc'
>>> to the PKG_CONFIG_PATH environment variable
>>> No package 'libtizcore' found
>>>
>>
>> This is not a problem. It seems to be optional requirement. I see the same
>> message in my build log.
>>
>> checking for RADEON... yes
>>> checking for RADEON... yes
>>> configure: error: LLVM 3.9.0 or newer is required for r600
>>>
>>
>> This is a problem. As it says, you need LLVM >= 3.9.0 and it did not find
>> one.
>>
>>
> Ah .. oops. Thanks for the reply and I should look closer before jumping
>  on the "what?" button.
>
> How very odd :
>
> root@xorg:~# apt-get install llvm
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> llvm is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
> root@xorg:~#
>
> Yet my old build process fails looking for LLVM?
>
> The funky Tizonia's OpenMAX IL Core thing isn't required and isn't even
> in the debian package list for that matter. Fine. However llvm is
> definately installed and has been for a long while.  I am just doing the
> usual per the instructions at :
>
> Testing X servers from git
> http://who-t.blogspot.com/2012/05/testing-x-servers-from-git.html
>
> That has worked since about 2013 however it has been a while since I
> tried. Something odd here ... not sure what it is yet.
>
> Dennis
>
>
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
>

Have you checked that the version installed of llvm is >= 3.9.0?
Debian Stretch by default install 3.8, while you can have 3.9 if
you install the llvm-toolchain-3.9 package. That should be enough.

-- 
Braiam Peguero
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: new dependency for libtizcore required for mesa?

2018-06-07 Thread Adam Jackson 
On Thu, 2018-06-07 at 11:06 -0400, Dennis Clarke wrote:

> Ah .. oops. Thanks for the reply and I should look closer before jumping
>   on the "what?" button.
> 
> How very odd :
> 
> root@xorg:~# apt-get install llvm
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> llvm is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
> root@xorg:~#
> 
> Yet my old build process fails looking for LLVM?

The package named 'llvm' is just the runtime. Typically any package you
need as a build dependency is going to be named llvm-dev on Debian-like 
systems.

- ajax
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: new dependency for libtizcore required for mesa?

2018-06-07 Thread Nigel Sollars 
Your most likely going to need to add a PPA for the LLVM you mention debian
( latest for deb is normally way behind required ) ..  I would imagine you
may need a couple to cover anything further.

Nige

On Thu, Jun 7, 2018 at 11:06 AM, Dennis Clarke 
wrote:

> On 6/7/18 10:44 AM, Michal Srb wrote:
>
>> On čtvrtek 7. června 2018 16:15:50 CEST Dennis Clarke wrote:
>>
>>> Package libtizcore was not found in the pkg-config search path.
>>> Perhaps you should add the directory containing `libtizcore.pc'
>>> to the PKG_CONFIG_PATH environment variable
>>> No package 'libtizcore' found
>>>
>>
>> This is not a problem. It seems to be optional requirement. I see the same
>> message in my build log.
>>
>> checking for RADEON... yes
>>> checking for RADEON... yes
>>> configure: error: LLVM 3.9.0 or newer is required for r600
>>>
>>
>> This is a problem. As it says, you need LLVM >= 3.9.0 and it did not find
>> one.
>>
>>
> Ah .. oops. Thanks for the reply and I should look closer before jumping
>  on the "what?" button.
>
> How very odd :
>
> root@xorg:~# apt-get install llvm
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> llvm is already the newest version.
> 0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
> root@xorg:~#
>
> Yet my old build process fails looking for LLVM?
>
> The funky Tizonia's OpenMAX IL Core thing isn't required and isn't even
> in the debian package list for that matter. Fine. However llvm is
> definately installed and has been for a long while.  I am just doing the
> usual per the instructions at :
>
> Testing X servers from git
> http://who-t.blogspot.com/2012/05/testing-x-servers-from-git.html
>
> That has worked since about 2013 however it has been a while since I
> tried. Something odd here ... not sure what it is yet.
>
> Dennis
>
>
> ___
> xorg@lists.x.org: X.Org support
> Archives: http://lists.freedesktop.org/archives/xorg
> Info: https://lists.x.org/mailman/listinfo/xorg
> Your subscription address: %(user_address)s
>



-- 
“Science is a differential equation. Religion is a boundary condition.”

  Alan Turing
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: new dependency for libtizcore required for mesa?

2018-06-07 Thread Dennis Clarke 

On 6/7/18 10:44 AM, Michal Srb wrote:

On čtvrtek 7. června 2018 16:15:50 CEST Dennis Clarke wrote:

Package libtizcore was not found in the pkg-config search path.
Perhaps you should add the directory containing `libtizcore.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libtizcore' found


This is not a problem. It seems to be optional requirement. I see the same
message in my build log.


checking for RADEON... yes
checking for RADEON... yes
configure: error: LLVM 3.9.0 or newer is required for r600


This is a problem. As it says, you need LLVM >= 3.9.0 and it did not find one.



Ah .. oops. Thanks for the reply and I should look closer before jumping
 on the "what?" button.

How very odd :

root@xorg:~# apt-get install llvm
Reading package lists... Done
Building dependency tree
Reading state information... Done
llvm is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 5 not upgraded.
root@xorg:~#

Yet my old build process fails looking for LLVM?

The funky Tizonia's OpenMAX IL Core thing isn't required and isn't even
in the debian package list for that matter. Fine. However llvm is
definately installed and has been for a long while.  I am just doing the
usual per the instructions at :

Testing X servers from git
http://who-t.blogspot.com/2012/05/testing-x-servers-from-git.html

That has worked since about 2013 however it has been a while since I 
tried. Something odd here ... not sure what it is yet.


Dennis

___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

Re: new dependency for libtizcore required for mesa?

2018-06-07 Thread Michal Srb 
On čtvrtek 7. června 2018 16:15:50 CEST Dennis Clarke wrote:
> Package libtizcore was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libtizcore.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'libtizcore' found

This is not a problem. It seems to be optional requirement. I see the same 
message in my build log.

> checking for RADEON... yes
> checking for RADEON... yes
> configure: error: LLVM 3.9.0 or newer is required for r600

This is a problem. As it says, you need LLVM >= 3.9.0 and it did not find one.

Michal
___
xorg@lists.x.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: https://lists.x.org/mailman/listinfo/xorg
Your subscription address: %(user_address)s

new dependency for libtizcore required for mesa?

2018-06-07 Thread Dennis Clarke 


Dear X-types:

Is there a new minimal dependency list?

While running a build I see this :

==
==  Processing:  "mesa/mesa"
==configuration options:
Cloning into 'mesa/mesa'...
remote: Counting objects: 1006300, done.
remote: Compressing objects: 100% (150111/150111), done.
remote: Total 1006300 (delta 859623), reused 996318 (delta 851198)
Receiving objects: 100% (1006300/1006300), 175.92 MiB | 5.00 MiB/s, done.
Resolving deltas: 100% (859623/859623), done.
Checking connectivity... done.
autoreconf: Entering directory `.'
autoreconf: configure.ac: not using Gettext
autoreconf: running: aclocal -I /opt/xorg/share/aclocal --force -I m4
autoreconf: configure.ac: tracing
autoreconf: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, `bin'.
libtoolize: copying file `bin/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
libtoolize: copying file `m4/libtool.m4'
libtoolize: copying file `m4/ltoptions.m4'
libtoolize: copying file `m4/ltsugar.m4'
libtoolize: copying file `m4/ltversion.m4'
libtoolize: copying file `m4/lt~obsolete.m4'
autoreconf: running: /usr/bin/autoconf --force
autoreconf: configure.ac: not using Autoheader
autoreconf: running: automake --add-missing --copy --force-missing
configure.ac:61: installing 'bin/ar-lib'
configure.ac:61: installing 'bin/compile'
configure.ac:45: installing 'bin/config.guess'
configure.ac:45: installing 'bin/config.sub'
configure.ac:46: installing 'bin/install-sh'
configure.ac:46: installing 'bin/missing'
src/Makefile.am: installing 'bin/depcomp'
parallel-tests: installing 'bin/test-driver'
autoreconf: Leaving directory `.'
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... no
checking for mawk... mawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether UID '16411' is supported by ustar format... yes
checking whether GID '20002' is supported by ustar format... yes
checking how to create a ustar tar archive... gnutar
checking whether make supports nested variables... (cached) yes
checking for style of include used by make... GNU
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for ar... ar
checking the archiver (ar) interface... ar
checking how to run the C preprocessor... gcc -E
checking for gcc... (cached) gcc
checking whether we are using the GNU C compiler... (cached) yes
checking whether gcc accepts -g... (cached) yes
checking for gcc option to accept ISO C89... (cached) none needed
checking whether gcc understands -c and -o together... (cached) yes
checking dependency style of gcc... (cached) gcc3
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking for grep that handles long lines and -e... /bin/grep
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking dependency style of gcc... gcc3
checking for GNU make... make
checking for python2.7... python2.7
checking for a sed that does not truncate output... /bin/sed
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking how to print strings... printf
checking for a sed that does not truncate output... (cached) /bin/sed
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking how to convert x86_64-unknown-linux-gnu file names to 
x86_64-unknown-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-unknown-linux-gnu file names to toolchain 
format... func_convert_file_noop

checking for /usr/bin/ld option to reload object files... -r
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to