bugGNU Octave - Bugs: bug #38564, llvm 3.2 does not provide required...

 
 

bug #38564: llvm 3.2 does not provide required header

Submitted by:  Michael Godfrey <godfrey>
Submitted on:  Thu 21 Mar 2013 04:42:07 PM UTC  
 
Category: Configuration and Build SystemSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Build Failure
Status: FixedAssigned to: None
Originator Name: Michael GodfreyOpen/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Wed 04 Sep 2013 05:02:06 PM UTC, comment #65:

Yes, why don't you file a new report. And is it only LLVM-3.2 that has this problem?

Rik <rik5>
Project Administrator
Wed 04 Sep 2013 04:28:48 PM UTC, comment #64:

The remaining problem is that 3.2 ends up using
static libraries even if the shared libraries are
available. The llvm config information does not,
as far as I could determine, provide a way of determining
if the shared libraries are available. A test of
their presence in the llvm lib directory seems to
be required.

To simplify things, maybe this should be made a new
bug report?

Michael Godfrey <godfrey>
Wed 04 Sep 2013 04:23:16 PM UTC, comment #63:

Can this bug be closed? I'm not sure which parts of it remain after the LLVM determination routines were overhauled in configure.ac.

Rik <rik5>
Project Administrator
Wed 14 Aug 2013 07:32:06 PM UTC, comment #62:

There was some side discussion of how to deal with
static vs. dynamic libraries. The main result is below:
Sorry about not keeping to the original bug report.
This report should probably re renamed to llvm 3.2 and newer
configuration problems.

>> On 08/11/2013 01:53 PM, Max Brister wrote:
>>>
>>> That would be good. I'm not sure what the problem is. Picking which
>>> libraries to link to hasn't changed since llvm 3.1. We just use
>>> llvm-config.
>>
>> I looked at this a bit more. It appears that the only method may be:
>> 1. Use llvm-config --libdir to find the library directory.
>> 2. Test for the needed *.so files in that directory. Is libLLVM-3.3.so
>> all that is needed?
>> 3. Set the right options for the linker.
>>
>> I have no idea why llvm-config --libnames produces the same output whether
>> the static libraries are installed of not, and anyhow only reports the
>> static libraries.
>>
>> How did this work in 3.1? Have you found a better way for 3.3?
>>
>> Michael
>>
>
> It looks like we might have to write the check ourselves for shared vs
> static libraries in configure.ac.
>


Why are messages suddenly being approved without moderation on this list?

Please use the bug tracker to post updates to a bug report. The
mailing list is intended as a read-only notification stream. Info
posted to this mailing list address won't appear in the tracker
database where it is most useful.

jwe

Michael Godfrey <godfrey>
Sun 04 Aug 2013 03:50:44 AM UTC, comment #61:

OK. Build completed JIT is running.

I had static libraries installed, so that needs
checking.

Michael Godfrey <godfrey>
Sun 04 Aug 2013 03:17:52 AM UTC, comment #60:

I did an hg update after the clone. This showed:
[pbdsl3:octave] hg update
72 files updated, 0 files merged, 0 files removed, 0 files unresolved
updating bookmark @
and the bookmark showed up at the top of the log.

This caused the patches to be committed and
./configure ran OK. Building now.

Michael Godfrey <godfrey>
Sun 04 Aug 2013 02:53:27 AM UTC, comment #59:

Right!

I noticed that the "bookmark" which Jordi
put in a while ago has gotten stuck below
our patches. I do not understand what the
bookmark is really supposed to do, but it
has something to do with commits...

Michael Godfrey <godfrey>
Sun 04 Aug 2013 02:47:42 AM UTC, comment #58:

Whew, I'm glad we figured out what was happening. I second the call for an hg wizard.

Max Brister <fisheater>
Project Member
Sun 04 Aug 2013 02:37:10 AM UTC, comment #57:

And, you are not alone. My changeset shown
just above yours did not get applied ether.

Michael Godfrey <godfrey>
Sun 04 Aug 2013 02:31:51 AM UTC, comment #56:

That is what I found. Progress, at least.

An hg wizard is called for...

Michael Godfrey <godfrey>
Sun 04 Aug 2013 02:30:07 AM UTC, comment #55:

I think something bad happened in hg. I just tried a fresh clone of Octave, and my patch is there but not applied.

Max Brister <fisheater>
Project Member
Sun 04 Aug 2013 02:28:21 AM UTC, comment #54:

Sorry, I spoke too soon again.

The diff for configure.ac in your patch
has no IR/Function.h

nor does the configure that results from ./bootstrap

So, is something wrong in ./bootstrap processing?

Michael Godfrey <godfrey>
Sun 04 Aug 2013 02:21:29 AM UTC, comment #53:

Something very odd here.

I did:
hg log -pr 17164:36fd98b9ce48 > ../llvm_patch
and compared the result with configure
after ./bootstrap and it appears as if
your patch did not get applied.

The file ../llvm_patch shows lines containing
IR/Function.h like:
+#include <llvm/IR/Function.h>

but that line is not in configure

Ideas?

Michael Godfrey <godfrey>
Sun 04 Aug 2013 02:11:35 AM UTC, comment #52:

I thought that default and devel were the same,
but I just use what you get by default.
And, I get:

[pbdsl3:octave] hg branches
default 17166:0e34c475c956
classdef 16896:498b2dd1bd56
stable 17112:eff3d78367f0 (inactive)

So, what I called devel is really default.

And, the problem is NOT solved.

What do you need to figure this out?

Michael Godfrey <godfrey>
Sun 04 Aug 2013 02:06:29 AM UTC, comment #51:

Which branch are you talking about. The only active branches I know about are default, stable, and classdef.
http://hg.savannah.gnu.org/hgweb/octave/branches

Max Brister <fisheater>
Project Member
Sun 04 Aug 2013 01:57:52 AM UTC, comment #50:

Any idea when this and other llvm patches will
be merged to devel?

Michael Godfrey <godfrey>
Sun 04 Aug 2013 01:41:19 AM UTC, comment #49:

That should be correct, are you on the default branch?

I was about to ask. NO on devel

That is surely the answer.

Michael Godfrey <godfrey>
Sun 04 Aug 2013 01:37:03 AM UTC, comment #48:

That should be correct, are you on the default branch?

Max Brister <fisheater>
Project Member
Sun 04 Aug 2013 01:31:24 AM UTC, comment #47:

I assume this is OK:

[pbdsl3:hg] source hg_clone
real URL is http://hg.savannah.gnu.org/hgweb/octave
destination directory: octave
requesting all changes

Michael Godfrey <godfrey>
Sun 04 Aug 2013 01:29:50 AM UTC, comment #46:

> grep "IR/Function.h" configure

in Octave's root directory? If that string doesn't exist, then your configure
script is out of date.

It is not there. But, I just downloaded and the result
shows your patch.

I will try again now.

Michael Godfrey <godfrey>
Sun 04 Aug 2013 01:25:54 AM UTC, comment #45:

I tried llvm 3.3rc3 and it configures correctly (build hasn't finished yet).

I'm confused as to why you don't get the following lines when configuring:
checking llvm/IR/Function.h usability... yes
checking llvm/IR/Function.h presence... yes

It leads me to believe that, for some reason, you're configure script isn't correct. Can you try running

> grep "IR/Function.h" configure

in Octave's root directory? If that string doesn't exist, then your configure script is out of date.

Max Brister <fisheater>
Project Member
Sun 04 Aug 2013 01:17:04 AM UTC, comment #44:

I should add that I am getting a bit worried about
Fedora's handling of some packages, like:

llvm in FC18 and 19 is shown as RCx, but it is
required by other packages which are fully released
and required. So, you cannot revert to a released
llvm (assuming that RC3 means NOT released).

Also, the released texlive is unworkable, but
other packages depend on it. They seem not to
know that the official source of TeX is CTAN.

Nothing is perfect...

Michael Godfrey <godfrey>
Sun 04 Aug 2013 01:11:04 AM UTC, comment #43:

Good idea.

My system is x86_64 and IRBuilder.h is at
[pbdsl3:octave] rpm -q --list llvm-devel-3.3-0.6.rc3.fc19.x86_64 | grep IRBuilder
290:/usr/include/llvm/IR/IRBuilder.h
[

Michael Godfrey <godfrey>
Sun 04 Aug 2013 01:09:14 AM UTC, comment #42:

Ok, it looks like you're on RC3, I'm going to try to compile on my system with RC3.

Max Brister <fisheater>
Project Member
Sun 04 Aug 2013 01:04:14 AM UTC, comment #41:

Your patch is definitely there:
changeset: 17164:36fd98b9ce48
user: Max Brister <max@2bass.com>
date: Sat Aug 03 16:53:46 2013 -0600
summary: Add support for llvm 3.3

It is surely significant that I am using the Fedora
"standard" llvm-3.3. Fedora 19 has been on this version
since it was released (and similar versions under fc18).

Notice that it still says rcX:
[pbdsl3:octave] rpm -qa | grep llvm
832:llvm-devel-3.3-0.6.rc3.fc19.x86_64
900:llvm-libs-3.3-0.6.rc3.fc19.x86_64
1399:llvm-3.3-0.6.rc3.fc19.x86_64
1654:llvm-static-3.3-0.6.rc3.fc19.x86_64
2178:llvm-debuginfo-3.3-0.6.rc3.fc19.x86_64
2584:llvm-doc-3.3-0.6.rc3.fc19.noarch

It is at the first reference to IR/ on your
system that fc19 goes wrong. It does not find .../IR/

Michael Godfrey <godfrey>
Sun 04 Aug 2013 12:57:10 AM UTC, comment #40:

Ok, I'm not sure what is happening here. IRBuilder.h is in
/usr/local/include/llvm/IR/IRBuilder.h
for me (I'm using a debug build of LLVM).

From your build log, it looks like it is skiping the llvm/IR/Function.h check as well. Can you run
hg log -l10

Is my patch applied?

What llvm configuration looks like on my system:
configure: using -isystem for LLVM headers
checking llvm/Support/TargetSelect.h usability... yes
checking llvm/Support/TargetSelect.h presence... yes
checking for llvm/Support/TargetSelect.h... yes
checking llvm/IR/Function.h usability... yes
checking llvm/IR/Function.h presence... yes
checking for llvm/IR/Function.h... yes
checking llvm/Support/IRBuilder.h usability... no
checking llvm/Support/IRBuilder.h presence... no
checking for llvm/Support/IRBuilder.h... no
checking llvm/IR/IRBuilder.h usability... yes
checking llvm/IR/IRBuilder.h presence... yes
checking for llvm/IR/IRBuilder.h... yes
checking llvm/Target/TargetData.h usability... no
checking llvm/Target/TargetData.h presence... no
checking for llvm/Target/TargetData.h... no
checking llvm/IR/DataLayout.h usability... yes
checking llvm/IR/DataLayout.h presence... yes
checking for llvm/IR/DataLayout.h... yes
checking check llvm::Function::addAttribute arg type is llvm::Attributes... no
checking check llvm::Function::addAttribute arg type is llvm::Attribute... yes
checking check LLVM::Function::addFnAttr arg type is llvm::Attributes... no
checking check llvm::Function::addFnAttr arg type is llvm::Attribute... yes
checking check LLVM::CallInst::addAttribute arg type is llvm::Attributes... no
checking check LLVM::CallInst::addAttribute arg type is llvm::Attribute... yes

Max Brister <fisheater>
Project Member
Sun 04 Aug 2013 12:52:04 AM UTC, comment #39:

I re-ran ./bootstrap;./configure --enable-jit
and got the same result:

checking for llvm-config... llvm-config
checking whether gcc accepts -isystem .... yes
configure: using -isystem for LLVM headers
checking llvm/Support/TargetSelect.h usability... yes
checking llvm/Support/TargetSelect.h presence... yes
checking for llvm/Support/TargetSelect.h... yes
checking llvm/IRBuilder.h usability... no
checking llvm/IRBuilder.h presence... no
checking for llvm/IRBuilder.h... no
checking llvm/Support/IRBuilder.h usability... no
checking llvm/Support/IRBuilder.h presence... no
checking for llvm/Support/IRBuilder.h... no
configure: error: IRBuilder.h is required.
[pbdsl3:octave]

Michael Godfrey <godfrey>
Sun 04 Aug 2013 12:34:13 AM UTC, comment #38:

Just to confirm my email to Max:

./configure --enable-jit

and got
checking for llvm-config... llvm-config
checking whether gcc accepts -isystem .... yes
configure: using -isystem for LLVM headers
checking llvm/Support/TargetSelect.h usability... yes
checking llvm/Support/TargetSelect.h presence... yes
checking for llvm/Support/TargetSelect.h... yes
checking llvm/IRBuilder.h usability... no
checking llvm/IRBuilder.h presence... no
checking for llvm/IRBuilder.h... no
checking llvm/Support/IRBuilder.h usability... no
checking llvm/Support/IRBuilder.h presence... no
checking for llvm/Support/IRBuilder.h... no
configure: error: IRBuilder.h is required.

This is llvm-3.3-0.6.rc3.fc19.x86_64 and libs and debug
in Fedora 19
On this system IRBuilder.h is found at:
/usr/include/llvm/IR/IRBuilder.h

Bug is still open.

Michael Godfrey <godfrey>
Sat 03 Aug 2013 10:58:27 PM UTC, comment #37:

I pushed a changeset that supports llvm 3.0 through 3.3.
http://hg.savannah.gnu.org/hgweb/octave/rev/36fd98b9ce48

I'm going to close this bug, however I'm sure a similar bug will get opened as soon as LLVM 3.4 is released.

Max Brister <fisheater>
Project Member
Mon 22 Jul 2013 12:38:21 AM UTC, comment #36:

I pushed LYH's patch with some minor modifications (whitespace/directory change).

LYH, I'll go ahead and add support for LLVM 3.3 so you can spend more time supporting more features.

Max Brister <fisheater>
Project Member
Mon 10 Jun 2013 08:42:31 PM UTC, comment #35:

A version of 3.3 is in the current release of
Fedora 18. Its name is:
llvm-3.3-0.4.rc2.fc18.x86_64
which sounds like testing (rc2) but someone
put it in the updates repository so it gets installed
if you do an update.

Anyhow, good to wait for the more official release.

Thanks!

Michael Godfrey <godfrey>
Sun 09 Jun 2013 06:23:36 PM UTC, comment #34:

Hello Michael,

LLVM((release candidate) is under testing. When the LLVM 3.3 is released, I will try to fix this.

LYH <lyh>
Thu 06 Jun 2013 06:00:38 PM UTC, comment #33:

More problems with llvm 3.3. After fixing
locations of .h files, I get:
interp-core/pt-jit.cc: In member function 'bool tree_jit::initialize()':
interp-core/pt-jit.cc:1864:26: error: expected type-specifier
interp-core/pt-jit.cc:1864:26: error: expected ')'
interp-core/pt-jit.cc:1864:69: error: no matching function for call to 'llvm::FunctionPassManager::add(int*)'
interp-core/pt-jit.cc:1864:69: note: candidate is:
In file included from interp-core/pt-jit.cc:53:0:
/usr/include/llvm/PassManager.h:81:8: note: virtual void llvm::FunctionPassManager::add(llvm::Pass*)
/usr/include/llvm/PassManager.h:81:8: note: no known conversion for argument 1 from 'int' to 'llvm::Pass'

:FunctionPassManager::add appears to have changed.

Michael Godfrey <godfrey>
Thu 06 Jun 2013 02:41:06 PM UTC, comment #32:

Sorry to say, this bug is back. llvm 3.3
(to be exact: llvm-devel-3.3-0.4.rc2.fc18.x86_64)
has moved Value.h from ../llvm to ../llvm/IR/
but apparently left the API level unchanged. It
appears that the llvm developers feel free to make
changes like this independent of API level.

So, while checking API level seems like a good idea,
it does not do the whole job. Would it make sense
to do the search for *.h files to include all
subdirectories (//) under ../include/llvm// ?

In any case, a change is needed to allow compiling
with llvm 3.3.

Michael Godfrey <godfrey>
Sun 05 May 2013 06:06:52 PM UTC, comment #31:

Using the API level sounds right.

It is not too helpful that the packagers
do not seem to talk with each other. This
happens with other packages as well.

Anyhow, thanks LYH for getting this done.

Michael Godfrey <godfrey>
Sun 05 May 2013 04:56:29 PM UTC, comment #30:

When I wrote this patch, I took into account support of multiple LLVM version. But what the patch detect is not LLVM version but LLVM API instead, as jwe and jordiGH suggested.

llvm-static or llvm-devel seems Linux distribution (package management) dependent. Under ubuntu, there isn't shared-library version of LLVM library. Apt install static-labrary version be default. Those doing testing on other platform should notice this situation.

In conclusion, support of liboctinterp.so linking with LLVM dynamic-library is reasonable to me.

By the way, who is responsible for pushing patch and managing bug report? I am new to Octave development.

Thanks

LYH <lyh>
Sun 05 May 2013 03:21:06 PM UTC, comment #29:

I tested this patch to the current devel
in F18 x86_64 with llvm 3.1 and it works
correctly.

So, it seems to make sense to push this
patch (subject to any testing on other systems)
and close this bug report.

But, then a new bug report should be opened
for the separate issue that llvm should use
dynamic linking instead of statically linking the
llvm libraries.

For those doing testing on other platforms it is
necessary to have llvm-static (new in llvm 3.2)
installed.

Michael Godfrey <godfrey>
Sun 05 May 2013 01:50:39 PM UTC, comment #28:

One final remark on this patch:

It appears that the llvm folks feel that changing
the API as a function of release version is OK.
Therefore, would it be better to use the release
level in the patch in order to decide which API
version is appropriate?

In any case, I will try applying the patch and
then compiling with llvm 3.1.

Michael Godfrey <godfrey>
Sun 05 May 2013 04:39:17 AM UTC, comment #27:

This is figured out. In llvm 3.1
the *.a files in /usr/lib64/llvm are provided
by llvm-devel. In 3.2 they are provided by
llvm-static. There is no llvm-static in
the llvm release 3.1 for Fedora.

So, it appears that llvm was being built with
static libraries all along.

It will probably be a good idea to change
this to dynamic at some point.

Michael Godfrey <godfrey>
Sun 05 May 2013 02:28:54 AM UTC, comment #26:

>My patch has no change with linking structure.


Useful to know.

I checked the yum.log on my systems and llvm-static
was first installed on 2 May, so I did not
have it installed when 3.0 was current.

I am trying a compile with llvm-static removed.

I will tell you what happens, but I agree that it
would be good to get results from other systems.

Michael Godfrey <godfrey>
Sun 05 May 2013 01:45:21 AM UTC, comment #25:

My patch has no change with linking structure. From my point of view, linking structure of JITC with either LLVM 3.1 or 3.2 are the same, just like what I mentioned previously.

Anyway, it seems that you have solved your problem currently. Maybe we can just wait another person try this patch and report the result if some error occurred.

By the way, Have you install llvm-static version 3.1 before?

LYH <lyh>
Sun 05 May 2013 12:54:46 AM UTC, comment #24:

I guessed that i-octave-3.2 was local to your system.

I am not sure about the context in which I got
llvm-3.2 to sucessfully link and run. I think that
llvm-static was installed, but I also think that I
caused /usr/lib64/llvm/ to be in the path, and that
it did a dynamic link. Unfortunately, I deleted
the test files, so I cannot check what really happened.
Sorry.

In any case, it seems to me that if the linking
structure as it was for 3.1 were left in place it
should work for 3.2. When I looked at it a while
ago I did not see any change in this area.

Have you tried this?

Michael Godfrey <godfrey>
Sat 04 May 2013 11:29:23 PM UTC, comment #23:

Sorry for misleading. i-octave-3.2 is the Octave prefix directory of my system.

I don't think so. According to your fail message. It did not appears -lLLVM-3.2svn argument. This implies linker wouldn't link libLLVM-3.2svn.so during linking liboctinterp.so.1.0.1.

How do you resolve the problem when you didn't install llvm-static? By eliminating the -lLLVM... stuff or adjusting path to the libs?

LYH <lyh>
Sat 04 May 2013 02:09:17 PM UTC, comment #22:

I could not find "i-octave-3.2" on my system.
But:
[pbdsl3:octave] grep -r "getPointerToFunction" *
Binary file libinterp/.libs/liboctinterp.so.1.0.1 matches
libinterp/interp-core/pt-jit.cc:2091: void *void_fn = engine->getPointerToFunction (llvm_function);
libinterp/interp-core/pt-jit.cc:2280: void *void_fn = engine->getPointerToFunction (llvm_function);
[pbdsl3:octave]
and:
[pbdsl3:octave] grep -r "getPointerToFunction" /usr/lib64/llvm/*
Binary file /usr/lib64/llvm/libLLVM-3.2svn.so matches
Binary file /usr/lib64/llvm/libLLVMExecutionEngine.a matches
Binary file /usr/lib64/llvm/libLLVMInterpreter.a matches
Binary file /usr/lib64/llvm/libLLVMJIT.a matches
Binary file /usr/lib64/llvm/libLLVMMCJIT.a matches

This shows that getPointerToFunction is defined in
Binary file /usr/lib64/llvm/libLLVM-3.2svn.so

As John suggested, this library would be a better
source for the functions than the static libraries.

Michael

Michael Godfrey <godfrey>
Sat 04 May 2013 05:50:13 AM UTC, comment #21:

Hi Michael,

Don't you install llvm-static in LLVM-3.1?

Could you follow my steps in comment #20 to find which library provides getPointerToFunction symbol?

Cheers

LYH <lyh>
Sat 04 May 2013 05:43:12 AM UTC, comment #20:

Hi John,

octave binary is linked with liboctinterp.so.1. However LLVM functions of liboctinterp.so.1 is extracted from llvm static library.

Take for example. getPointerFunction is the entry point of LLVM JIT

$ldd ./i-octave-3.2/bin/octave
...
liboctinterp.so.1 => /home/lyh/Desktop/Octave/b-octave-3.2/../i-octave-3.2/lib/octave/3.7.3+/liboctinterp.so.1 (0x00007fe156446000)
...

$ grep -r "getPointerToFunction" ./i-octave-3.2/lib/
Binary file ./i-octave-3.2/lib/octave/3.7.3+/liboctinterp.so.1.0.1 matches

$ grep -r "getPointerToFunction" ./i-llvm-3.2/lib/
Binary file ./i-llvm-3.2/lib/libLLVMJIT.a matches
Binary file ./i-llvm-3.2/lib/libLLVMInterpreter.a matches
Binary file ./i-llvm-3.2/lib/libLLVMMCJIT.a matches
Binary file ./i-llvm-3.2/lib/libLLVMExecutionEngine.a matches

Above shows that getPointerToFunction sumbol appears only in llvm static libaray(default) and liboctinterp.so.1.0.1

Cheers

LYH <lyh>
Sat 04 May 2013 04:53:35 AM UTC, comment #19:

Are you building a statically linked binary? If not, then I would expect that you would link with .so files on a modern system and not need any .a files.

John W. Eaton <jwe>
Project Administrator
Sat 04 May 2013 04:49:27 AM UTC, comment #18:

I just found something useful:
rpm -q --whatprovides /usr/lib64/llvm/libLLVMARMAsmParser.a
llvm-static-3.2-2.fc18.x86_64

So, in order for the *.a files to be found, llvm-static
needs to be installed. I do not think that this was
the way it worked previously.

Part of my confusion came from the fact that I have 2 systems,
As I just discovered, one had llvm-static and the other did not.

Michael Godfrey <godfrey>
Sat 04 May 2013 04:12:16 AM UTC, comment #17:

Yes, it seems that those *.so files are not the needed llvm libs.

According to your fail message. Each "/usr/bin/ld: cannot find -lLIBNAME" means that your linker should link with libLIBNAME.a. Take an example: /usr/bin/ld: cannot find -lLLVMAsmParser means that your linker should link with libLLVMAsmParser.a

So when I type ls `llvm-config --libdir`. I could see libLLVMAsmParser.a in directory. How about you? What *a are there in your /usr/lib64/llvm?

By the way, you said that you edit Makefile by hand and it works. How do you edit. Could you tell me more details?

LYH <lyh>
Sat 04 May 2013 12:59:52 AM UTC, comment #16:

I just took a look, and the listed *.so files
are all there is in
rpm -q --list llvm-libs-3.2-2.fc18.x86_64
/etc/ld.so.conf.d/llvm-x86_64.conf
/usr/lib64/llvm
/usr/lib64/llvm/BugpointPasses.so
/usr/lib64/llvm/LLVMgold.so
/usr/lib64/llvm/libLLVM-3.2svn.so
/usr/lib64/llvm/libLTO.so
/usr/lib64/llvm/libprofile_rt.so

Michael Godfrey <godfrey>
Sat 04 May 2013 12:56:15 AM UTC, comment #15:

Here are the answers:
[pbdsl4:godfrey] llvm-config --version
3.2svn
[pbdsl4:godfrey] llvm-config --libdir
/usr/lib64/llvm
[pbdsl4:godfrey] ls /usr/lib64/llvm
BugpointPasses.so* libLLVM-3.2svn.so* libLTO.so* libprofile_rt.so* LLVMgold.so*

The ls /usr/lib64/llvm result doe not look right.
Those *.so files are not the needed llvm libs are they?

Michael

Michael Godfrey <godfrey>
Fri 03 May 2013 09:38:21 PM UTC, comment #14:

I have take a look of your fail message. It seems that you don't put -L `llvm-config --libdir` in linking command.

What is your output of llvm-config --version? llvm-config --libdir?

If you list the directory of llvm-config --libdir. Do you see the missed libs?

LYH

LYH <lyh>
Fri 03 May 2013 09:16:31 PM UTC, comment #13:

My earlier comments were a bit confused, and it
is still not clear what is happening. But, I believe
that the setting of LLVM_LIBS is correct, but somehow
the path to the libs gets lost when ln is run
in libinterp.

For: which llvm-config I get:
which llvm-config
/usr/bin/llvm-config

[root@pbdsl4 ~]# ls -l /usr/bin/llvm-config
lrwxrwxrwx 1 root root 29 Apr 5 19:18 /usr/bin/llvm-config -> /etc/alternatives/llvm-config

But, this points to:
[root@pbdsl4 ~]# ls -l /etc/alternatives/llvm-config
lrwxrwxrwx 1 root root 23 Apr 5 19:18 /etc/alternatives/llvm-config -> /usr/bin/llvm-config-64

Which is:
[root@pbdsl4 ~]# ls -l /usr/bin/llvm-config-64
-rwxr-xr-x 1 root root 247968 Mar 13 11:20 /usr/bin/llvm-config-64

I do not think that I set any of these links.

I also noticed that the system has an llvm-config link in
/bin as well as /usr/bin. Both point to the same link.

And:
[pbdsl3:godfrey] rpm -q --whatprovides /usr/bin/llvm-config-64
llvm-devel-3.2-2.fc18.x86_64

Shows that the found llvm-config-64 is for llvm-3.2.
The update to 3.2 replaced the previous llvm.

Anything more I can add?

Michael

Michael Godfrey <godfrey>
Fri 03 May 2013 08:33:00 AM UTC, comment #12:

Hi Michael,

LLVM_LIBS depends on llvm-config. When I use apt to install llvm-dev under ubuntu. I need create a symbolic link pointer to llvm-config-3.2. Have you do so? What is your output when you type $which llvm-config

Thanks a lot

LYH

LYH <lyh>
Thu 02 May 2013 06:09:47 PM UTC, comment #11:

I looked at this a bit more. The problem is not with the
LLVM_LIBS =
line. It is due to the fact that the path to the libs somehow
is not found. But, when I di some editing and then, I think,
put everything back, it worked!!

Right now I have very little time (lectures to prepare)...
But, I will try to locate the problem when I can. Anyone who
may know the environment setup better is welcome to go ahead!

Michael

Michael Godfrey <godfrey>
Wed 01 May 2013 05:02:38 PM UTC, comment #10:

Good to hear from you.

I had no problem with llvm 3.1

My Fedora system got updated to 3.2 on 20 March,
so my ability to compile with llvm stopped then.

Obviously, configure is getting confused and appends
all that stuff to
LLVM_LIBS =

I assume that on your system either LLVM_LIBS
is empty or has some libraries that are not found
otherwise. Correct?

Someone with good experience with configure and
Fedora should be able to fix this pretty easily.

Anyhow, thanks very much for contributing this
patch.

Michael

Michael Godfrey <godfrey>
Wed 01 May 2013 03:11:09 PM UTC, comment #9:

Hi Michael,

The patch is submitted by me. My OS is ubuntu. I don't encounter the problem you mentioned. Do you have the same problem with LLVM-3.1?

LYH

LYH <lyh>
Wed 01 May 2013 12:38:11 PM UTC, comment #8:

I ran a few tests and JIT seems to be working as before.

So, the only problem with this patch seems to be getting
the LLVM_LIBS = to be correct for Fedora 18 and possibly
other systems.

The patch was submitted by "anonymous." Does anyone
take credit for this?

Michael

Michael Godfrey <godfrey>
Wed 01 May 2013 12:00:46 PM UTC, comment #7:

After running ./configure, I edited the Makefile to eliminate
the -lLLVM... stuff so that:
Makefile:1191:LLVM_LIBS =
instead.

This worked and the build passes make check

So, fixing the incorrect LLVM_LIB = should
make this patch ready to be pushed.

Michael Godfrey <godfrey>
Wed 01 May 2013 03:06:51 AM UTC, comment #6:

The patch attached below (llvm-api.patch)
helps, fails when linking. Looks like a
minor problem, but...

The attached file: patch_fail shows the
problem.

This is on Fedora 18 x86_64 with latest
llvm:
1385:llvm-3.2-2.fc18.x86_64
1965:llvm-libs-3.2-2.fc18.x86_64
2271:llvm-devel-3.2-2.fc18.x86_64

Michael

(file #27986)

Michael Godfrey <godfrey>
Mon 08 Apr 2013 03:00:12 PM UTC, comment #5:

I tried to resolve the problem with JIT and llvm 3.2.
There is some guidance on the web at the llvm site, but
it ends with the statment that the API has been changed
and users will just have to change their code to adapt.

I do not know enough about the JIT implementation to even
start on this.

Is there a volunteer?

Michael Godfrey <godfrey>
Thu 21 Mar 2013 06:42:55 PM UTC, comment #4:

I put the link in the right place. It resolved the
file not found for IRBuilder.h, but produced new
errors.

It appears that the llvm folks did this, but there
is a statement, apparently by them, that "3.2 is not
officially released and has missing files."

So, it may be that the Fedora packagers jumped the
gun. That is why I tried a downgrade of llvm.

This is pretty surely up to llvm/fedora to fix.
Just thought it was worth reporting here since it
will happen to others.

Michael Godfrey <godfrey>
Thu 21 Mar 2013 06:36:58 PM UTC, comment #3:

Is the link you made actually in "/usr/include/Support" or is it in "/usr/include/llvm/Support". It needs to be in the latter.

Also, has the LLVM project been moving files around or is this something that the packagers at Fedora have done? We don't want to chase compatibility with every single distribution.

Rik <rik5>
Project Administrator
Thu 21 Mar 2013 05:11:47 PM UTC, comment #2:

In 3.2 IRBuilder.h has been moved to /usr/include/llvm/
But, including a link to it in /usr/include/Support/
does not fix the problem.

There seems to be some confusion about the "release"
of 3.2. But the current fc18 requires it.

Michael Godfrey <godfrey>
Thu 21 Mar 2013 04:50:14 PM UTC, comment #1:

I took a quick look at 3.1 vs. 3.2. It looks a lot
like the IRBuilder.h file just accidentally got
left out of the 3.2 release for fedora 18. The use
of IRBuilder is mentioned in other header files.

Michael Godfrey <godfrey>
Thu 21 Mar 2013 04:42:07 PM UTC, original submission:

In llvm 3.1 :
/usr/include/llvm/Support/IRBuilder.h
exists. In 3.2 it does not. Therefore
the current devel build fails with:
interp-core/.libs/interp_core_libinterp_core_la-jit-ir.o
interp-core/jit-typeinfo.cc:42:36: fatal error: llvm/Support/IRBuilder.h: No such file or directory

Michael Godfrey <godfrey>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #27987:  llvm-api.patch added by None (11kB - application/octet-stream - patch from LYH(w/ autoconf))
file #27986:  patch_fail added by godfrey (6kB - application/octet-stream)
file #27984:  llvm-api.patch added by None (10kB - application/octet-stream - Handle LLVM3.1 and LLVM3.2 API incoherence - patch from LYH (w/ autoconf))
file #27977:  llvm32 added by None (3kB - application/octet-stream - patch from LYH at #octave (w/o autoconf))

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mtmiller (Updated the item)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by fisheater (Posted a comment)
  • -unavailable- added by jordigh (Updated the item)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by lyh (Posted a comment)
  • -unavailable- added by godfrey (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 13 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 07 Sep 2013 12:09:43 AM UTCmtmillerStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Sun 04 Aug 2013 02:30:07 AM UTCfisheaterStatusWorks For Me=>None
    Sun 04 Aug 2013 12:57:10 AM UTCfisheaterStatusFixed=>Works For Me
      Open/ClosedClosed=>Open
    Sat 03 Aug 2013 10:58:27 PM UTCfisheaterStatusPatch Submitted=>Fixed
      Open/ClosedOpen=>Closed
    Wed 22 May 2013 04:24:10 PM UTCjordighStatusNone=>Patch Submitted
    Fri 03 May 2013 05:18:59 PM UTCrik5Carbon-CopyRemoved 72865=>-
    Wed 01 May 2013 02:47:04 PM UTCNoneAttached File-=>Added llvm-api.patch, #27987
    Wed 01 May 2013 03:06:51 AM UTCgodfreyAttached File-=>Added patch_fail, #27986
    Tue 30 Apr 2013 06:03:30 PM UTCNoneAttached File-=>Added llvm-api.patch, #27984
    Mon 29 Apr 2013 02:23:18 PM UTCNoneAttached File-=>Added llvm32, #27977

    Back to the top


    Powered by Savane 3.1-cleanup