but, still it fails in runtime

libGL: OpenDriver: trying /usr/lib32/dri/tls/r600_dri.so
libGL: OpenDriver: trying /usr/lib32/dri/r600_dri.so
libGL error: dlopen /usr/lib32/dri/r600_dri.so failed (/usr/lib32/dri/r600_dri.so: undefined symbol: setupterm)
libGL error: unable to load driver: r600_dri.so
libGL error: driver pointer missing
libGL error: failed to load driver: r600
libGL: OpenDriver: trying /usr/lib32/dri/tls/swrast_dri.so
libGL: OpenDriver: trying /usr/lib32/dri/swrast_dri.so
libGL error: dlopen /usr/lib32/dri/swrast_dri.so failed (/usr/lib32/dri/swrast_dri.so: undefined symbol: setupterm)
libGL error: unable to load driver: swrast_dri.so
libGL error: failed to load driver: swrast

Hi David

Try building llvm without terminfo and see if you get the same issue
On 13 Oct 2013 00:12, <bugzilla-daemon@freedesktop.org> wrote:

>   *Comment # 1 <https://bugs.freedesktop.org/show_bug.cgi?id=70410#c1> on bug
> 70410 <https://bugs.freedesktop.org/show_bug.cgi?id=70410> from David
> "okias" Heidelberger <david.heidelberger@ixit.cz> *
>
> but, still it fails in runtime
>
> libGL: OpenDriver: trying /usr/lib32/dri/tls/r600_dri.so
> libGL: OpenDriver: trying /usr/lib32/dri/r600_dri.so
> libGL error: dlopen /usr/lib32/dri/r600_dri.so failed
> (/usr/lib32/dri/r600_dri.so: undefined symbol: setupterm)
> libGL error: unable to load driver: r600_dri.so
> libGL error: driver pointer missing
> libGL error: failed to load driver: r600
> libGL: OpenDriver: trying /usr/lib32/dri/tls/swrast_dri.so
> libGL: OpenDriver: trying /usr/lib32/dri/swrast_dri.so
> libGL error: dlopen /usr/lib32/dri/swrast_dri.so failed
> (/usr/lib32/dri/swrast_dri.so: undefined symbol: setupterm)
> libGL error: unable to load driver: swrast_dri.so
> libGL error: failed to load driver: swrast
>
>  ------------------------------
> You are receiving this mail because:
>
>    - You are the assignee for the bug.
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>

        --enable-terminfo=no
        --enable-curses=no
it works well, after this. Thank you.

But it has still problem described in bugreport (if this two options arent passed to llvm).

Out of interest which compiler are you using and which linker?

I'm sure I was seeing this with gcc 4.7 and ld.bfd but not on my gcc 4.8
system with ld.gold (both llvm's were compiled with the gold use flag
though)

I've not seen any issues on the gcc 4.7 system since upgrading to 4.8 still
with ld.bfd

I did have --disable-terminfo in the llvm build in my overlay but I figured
the problem was fixed so removed it and carried on using 9999 from portage
- hopefully we can figure out the root cause though


On 13 October 2013 01:07, <bugzilla-daemon@freedesktop.org> wrote:

>   *Comment # 3 <https://bugs.freedesktop.org/show_bug.cgi?id=70410#c3> on bug
> 70410 <https://bugs.freedesktop.org/show_bug.cgi?id=70410> from David
> "okias" Heidelberger <david.heidelberger@ixit.cz> *
>
>         --enable-terminfo=no
>         --enable-curses=no
> it works well, after this. Thank you.
>
> But it has still problem described in bugreport (if this two options arent
> passed to llvm).
>
>  ------------------------------
> You are receiving this mail because:
>
>    - You are the assignee for the bug.
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>

The Gentoo bug is https://bugs.gentoo.org/show_bug.cgi?id=481316

I've readded llvm-9999-r1 to my overlay again with --disable-terminfo until the problem is fixed

I'm pretty sure this is a bug in LLVM (probably llvm-config) or maybe the way we compile LLVM in Gentooland

Either way I think this bug should be closed

It seems that compiling mesa with --with-llvm-shared-libs when ever llvm is used rather than just with opencl fixes the issue to (at least for me)

in ixit overlay I yesterday added configurable llvm [ncurses,tinfo]. I'm using gcc-4.9-git, but it was same with gcc-4.8.0

llvm-config now has this parameter:

  --system-libs     System Libraries needed to link against LLVM components.

And on my system it outputs:

  -lz -lpthread -lffi -lcurses -ldl -lm

This should be added to LDFLAGS when you are statically linking to llvm libraries. Because of this, libclc is also broken.

(In reply to comment #8)
> llvm-config now has this parameter:
> 
>   --system-libs     System Libraries needed to link against LLVM components.
> 
> And on my system it outputs:
> 
>   -lz -lpthread -lffi -lcurses -ldl -lm
> 
> This should be added to LDFLAGS when you are statically linking to llvm
> libraries. Because of this, libclc is also broken.

What output this command produces?
llvm-config-3.5 --system-libs|wc -l

On my system llvm-config-3.5 --system-libs adds a problematic new line, that breaks generated Makefile. Thus an ugly hack might be needed.

Same here, but I use llvm-3.4 release. You could easily strip the new line using sed or whatever.

llvm-config --ldflags
-L/usr/lib  -lz -lpthread -lffi -lcurses -ldl -lm 

There's also this command which doesn't add new line, at least not here.

Oh, I'm sorry for multiple posts. Seems that I've downgraded to llvm-3.4 but I was using 3.5 snapshot and that's why --ldflags works for me as it is - there's no --system-libs option. You could easily fill a bug for llvm 3.5 since it's still in development

Created attachment 91725 [details]
Another patch, with newline hack

llvm-config --ldflags:
-L/usr/lib/llvm-3.5/lib

Needed libraries are not included

I would be glad I someone tested it with llvm 3.4 and 3.5.
I have tested it myself, but I want to be sure.

Created attachment 91751 [details] [review]
llvm-config patch to place system-libs on a single line

Patch modifies llvm-config to print --system-libs on a single line.

If the user requests 'llvm-config --libs --system-libs', then it still puts it on a single line, but orders the system libraries to come at the end. If you request --libs, then you just get libs. If you request --system-libs, then you just get system libraries that llvm links against.

This way we just have to modify the mesa build to call 'llvm-config --libs --system-libs' anywhere needed, instead of doing some sed fiddling to the output and hoping we get it right.

Created attachment 91763 [details] [review]
--system-libs patch without newline hack

Hack free version of patch

Created attachment 91764 [details] [review]
--system-libs patch without newline hack

A cleaner version

I've tested attachment 91725 [details] and it works with LLVM 3.5 (r198682) in a clean build enviroment (LLVM packages for Debian from llvm.org/apt).

I couldn't use attachment 91764 [details] [review], since apparently the patch from attachment 91751 [details] [review] hasn't landed in LLVM's tree yet (at least not before r198682).

You can have my
Tested-by: Kai Wasserbäch <kai@dev.carbon-project.org>
for attachment 91725 [details].

Stack:
LLVM: SVN:trunk/r198682
Mesa: Git:master/532b1fecd9
libdrm: 2.4.50-1 (Debian package)

(In reply to comment #17)
> I've tested attachment 91725 [details] and it works with LLVM 3.5 (r198682)
> in a clean build enviroment (LLVM packages for Debian from llvm.org/apt).
> 
> I couldn't use attachment 91764 [details] [review] [review], since apparently the
> patch from attachment 91751 [details] [review] [review] hasn't landed in LLVM's tree
> yet (at least not before r198682).
> 
> You can have my
> Tested-by: Kai Wasserbäch <kai@dev.carbon-project.org>
> for attachment 91725 [details].
> 
> Stack:
> LLVM: SVN:trunk/r198682
> Mesa: Git:master/532b1fecd9
> libdrm: 2.4.50-1 (Debian package)

Thank You for Your help, I will wait for LLVM to fix newline problem, before sending this patch to mesa-dev

Patch sent to mesa-dev, if included I will close this bug, for now.

Patch increase size a lot. Linking failure is fixed when enable-shared-llvm option isn't enabled. Something is weird somewhere

I am not a developer, but try to test upstream code related to my GPU (RadeonSI) to catch problems early.  It can be weeks (sometimes even months) between builds for me if real life gets busy.

I switched from LLVM 3.4 to LLVM 3.5 about 2 weeks ago, and began trying to get my local Mesa build back into shape.  Instead of building my own LLVM, I rely on daily builds provided for Debian by a maintainer; a problem with symlinks was resolved recently (bug 75919).  Also, the internal configure.ac changes with "--enable-llvm-shared-libs" stung me (bug 75929), but that has been fixed as well.

But I still cannot build without attachment 91725 [details] above.  The LLVM fix referenced in this bug seems to have made it upstream (rev 202719), but that hasn't prevented my need for the patch.

For now I have created a local Mesa branch with this patch so I do not have to keep manually applying it before a build.

(In reply to comment #21)
> I am not a developer, but try to test upstream code related to my GPU
> (RadeonSI) to catch problems early.  It can be weeks (sometimes even months)
> between builds for me if real life gets busy.
> 
> I switched from LLVM 3.4 to LLVM 3.5 about 2 weeks ago, and began trying to
> get my local Mesa build back into shape.  Instead of building my own LLVM, I
> rely on daily builds provided for Debian by a maintainer; a problem with
> symlinks was resolved recently (bug 75919).  Also, the internal configure.ac
> changes with "--enable-llvm-shared-libs" stung me (bug 75929), but that has
> been fixed as well.
> 
> But I still cannot build without attachment 91725 [details] above.  The LLVM
> fix referenced in this bug seems to have made it upstream (rev 202719), but
> that hasn't prevented my need for the patch.
> 
> For now I have created a local Mesa branch with this patch so I do not have
> to keep manually applying it before a build.

What configure flags are you using for mesa?  What error do you get when you try to build mesa?

(In reply to comment #22)
> > But I still cannot build without attachment 91725 [details] above.  The LLVM
> > fix referenced in this bug seems to have made it upstream (rev 202719), but
> > that hasn't prevented my need for the patch.
> > 
> What configure flags are you using for mesa?  What error do you get when you
> try to build mesa?

It was PEBKAC.  Sorry for the noise.

Before I wrote comment 21, I had performed builds on Mar. 8, Mar. 10, and Mar. 11.  I believed I was testing an unpatched Mesa from Mar. 11 (a few days old), but it must have been tampered with by myself.  (I had been trying several different daily builds of LLVM 3.5 as well.)  I have been busy for a busy for a few days, and have only now found time to return to this problem.

Just now I was able to build a fresh, definitely untampered Mesa tree with no errors at all.  I have no idea what stupidity I was doing a couple of days ago....

Afaict system-libs should not be used when linking against shared llvm. I've just pushed a similar patch which should resolve the problems with static llvm, while preserving the shared one as is.

commit af9551e68c8c964a3a80d74b6ed543b800318b33
Author: Jan Vesely <jan.vesely@rutgers.edu>
Date:   Thu Oct 23 17:17:07 2014 -0400

    configure: include llvm systemlibs when using static llvm

    v2: drop -WL,--exclude-libs, it's not necessary
        fix tabs/spaces