bugGNU Octave - Bugs: bug #39942, Allow shared libs for llvm 3.2

 
 

bug #39942: Allow shared libs for llvm 3.2

Submitter:  Michael Godfrey <godfrey>
Submitted:  Wed 04 Sep 2013 06:22:48 PM UTC
   
 
Category:  Configuration and Build System Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Performance
Status:  Fixed Assigned to:  lostbard
Originator Name:  Michael Godfrey Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 07 Sep 2013 12:00:00 AM UTC, comment #20: 

Works for me on Debian with LLVM 3.2. Thanks.

Mike Miller <mtmiller>
Group Member
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.

John Donoghue <lostbard>
Group Member
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.

John Donoghue <lostbard>
Group Member
Fri 06 Sep 2013 09:53:19 PM UTC, comment #17: 

OK. New build with patch works just fine.
FC19 x86_64

Thanks!

Michael Godfrey <godfrey>
Group Member
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.

Michael Godfrey <godfrey>
Group Member
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.

Michael Godfrey <godfrey>
Group Member
Fri 06 Sep 2013 08:58:36 PM UTC, comment #14: 

I meant to say:
I used: ./configure--enable-jit; make

Michael Godfrey <godfrey>
Group Member
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.

Michael Godfrey <godfrey>
Group Member
Fri 06 Sep 2013 06:46:02 PM UTC, comment #12: 

The patch works for me in Fedora 19 x86_64

Thanks!

Michael Godfrey <godfrey>
Group Member
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.

John Donoghue <lostbard>
Group Member
Fri 06 Sep 2013 05:14:57 PM UTC, comment #10: 

Yes, I think so.  I will give it a try soon.

Michael Godfrey <godfrey>
Group Member
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.

Mike Miller <mtmiller>
Group Member
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.

Michael Godfrey <godfrey>
Group Member
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?

John Donoghue <lostbard>
Group Member
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.

Michael Godfrey <godfrey>
Group Member
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.

John Donoghue <lostbard>
Group Member
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...

Michael Godfrey <godfrey>
Group Member
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.

John Donoghue <lostbard>
Group Member
Fri 06 Sep 2013 01:22:27 PM UTC, comment #2: 

AFAIK, LLVM does not support shared libraries under Windows. It's only static.

Michael Goffioul <goffioul>
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)

John Donoghue <lostbard>
Group Member
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.

Michael Godfrey <godfrey>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #29024:  llvm_dyn.patch added by lostbard (1KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by lostbard (Updated the item)
  • -email is unavailable- added by godfrey (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-09-11 lostbard StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2013-09-07 lostbard StatusNone Ready For Test
        Assigned toNone lostbard
    2013-09-06 lostbard Attached File- Added llvm_dyn.patch, #29024

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code