Sat 07 Sep 2013 12:00:00 AM UTC, comment #20:
Works for me on Debian with LLVM 3.2. Thanks.
|
Fri 06 Sep 2013 11:45:37 PM UTC, comment #19:
Pushed - http://hg.savannah.gnu.org/hgweb/octave/rev/2b4ed68be0d5
I might need to add for mingw/windows however want to play around with it in both cross and native builds for mingw first.
|
Fri 06 Sep 2013 11:16:14 PM UTC, comment #18:
ok - I guess I will push the patch and see if anyone has any problems - worst case should be that it uses the static instead of dynamic libs which is what it already does.
|
Fri 06 Sep 2013 09:53:19 PM UTC, comment #17:
OK. New build with patch works just fine.
FC19 x86_64
Thanks!
|
Fri 06 Sep 2013 09:06:51 PM UTC, comment #16:
Please forget the last 2 comments. I forgot to
reapply the patch for the new build
Better report soon! Sorry.
|
Fri 06 Sep 2013 09:03:39 PM UTC, comment #15:
In the result of ./configure--enable-jit there is:
LLVM LDFLAGS: -L/usr/lib64/llvm
LLVM libraries: -lLLVMInstrumentation -lLLVMArchive -lLLVMLinker -lLLVMIRReader -lLLVMBitRead ... and so on
This line last line is not correct.
|
Fri 06 Sep 2013 08:58:36 PM UTC, comment #14:
I meant to say:
I used: ./configure--enable-jit; make
|
Fri 06 Sep 2013 08:56:26 PM UTC, comment #13:
Oops, I spoke too soon. I ran a build doing
./configure; make
with the static libs removed, but this actually
used the static libs from the previous builds.
Building a new system ends with:
libtool: link: g++ -fPIC -DPIC -shared -nostdlib
....
/usr/bin/ld: cannot find -lLLVMInstrumentation
/usr/bin/ld: cannot find -lLLVMArchive
/usr/bin/ld: cannot find -lLLVMLinker
/usr/bin/ld: cannot find -lLLVMIRReader
/usr/bin/ld: cannot find -lLLVMBitReader
/usr/bin/ld: cannot find -lLLVMAsmParser
/usr/bin/ld: cannot find -lLLVMDebugInfo
...
and so on.
|
Fri 06 Sep 2013 06:46:02 PM UTC, comment #12:
The patch works for me in Fedora 19 x86_64
Thanks!
|
Fri 06 Sep 2013 06:08:42 PM UTC, comment #11:
I gave a quick try in windows, and see that it will also need to add the bindir path to the library search path as well (if in Windows). The rest of the patch works.
|
Fri 06 Sep 2013 05:14:57 PM UTC, comment #10:
Yes, I think so. I will give it a try soon.
|
Fri 06 Sep 2013 04:18:19 PM UTC, comment #9:
Isn't that exactly what the attached patch does? I have not yet tested it but it looks right to me.
|
Fri 06 Sep 2013 04:14:17 PM UTC, comment #8:
Basically, this is right. But, the path has to
be followed to see if the shared libraries are actually
there. llvm-config returns the same results whether the
shared libraries are present or not. A test for any
*.so files may be the best choice since the actual name
of the shared library is version-specific in a way that
may vary.
|
Fri 06 Sep 2013 03:33:24 PM UTC, comment #7:
cant we see if the library is there in the llvm-config path and use it, otherwise fall back to trying to detect the static libs as it currently does?
|
Fri 06 Sep 2013 02:58:41 PM UTC, comment #6:
The problem with using llvm-config is that it
returns the path whether the shared libraries are
present or not. I think that the
/etc/ld.so.conf.d/llvm-x86_64.conf is
only present if the shared libraries are installed.
At least, this is the case in the Fedora package.
|
Fri 06 Sep 2013 02:53:50 PM UTC, comment #5:
llvm-config returns the library path, which is what I used in the patch, and used the output of llvm-config for the version number to append to the library name.
So patch should work for your system.
|
Fri 06 Sep 2013 02:42:15 PM UTC, comment #4:
In Fedora, llvm-libs.x86_64 provides:
[root@pbdsl3 octave]# rpm -q --list llvm-libs.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.3.so
/usr/lib64/llvm/libLTO.so
/usr/lib64/llvm/libprofile_rt.so
I think that only libLLVM-3.3.so is normally required.
When I looked this up I noticed:
/etc/ld.so.conf.d/llvm-x86_64.conf
This contains:
/usr/lib64/llvm
So, it may be appropriate to use this file to test for
shared libraries and their location. Of course, this
could be system type dependent...
|
Fri 06 Sep 2013 01:38:50 PM UTC, comment #3:
The current .mk file in mxe-octave doesn't build it, however I have been able to generate the dll - just haven't tried using it to see if it works.
I'll play around with the dynamic llvm in windows and see what it does.
|
Fri 06 Sep 2013 01:22:27 PM UTC, comment #2:
AFAIK, LLVM does not support shared libraries under Windows. It's only static.
|
Fri 06 Sep 2013 10:26:24 AM UTC, comment #1:
Is the dynamic llvm library always one big library as in fedora and windows?
If so, how about something like this? (attached)
(file #29024)
|
Wed 04 Sep 2013 06:22:48 PM UTC, original submission:
This report follows from #38564.
The problem that remained from fixing the
llvm 3.2 configuration was:
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.
Rik: I am fairly sure that 3.1 used shared libs if
available, but I have not checked this. And, I no
longer have a system with llvm 3.1 installed.
I think that John in particular prefers use of
shared libs, and this makes sense to me. The smaller
Octave is the better. That is why I marked this
as a performance issue.
|