[Openmp-dev] (no subject)

[Hal Finkel]

----- Original Message -----
> From: "Jack Howarth" <howarth.mailing.lists at gmail.com>
> To: "Hal Finkel" <hfinkel at anl.gov>
> Cc: openmp-dev at dcs-maillist2.engr.illinois.edu, "C. Bergström" <cbergstrom at pathscale.com>
> Sent: Friday, May 30, 2014 6:21:19 PM
> Subject: Re: [Openmp-dev] (no subject)
> 
> 
> Hal,
> Also note that they are replicating the build from build.pl down to
> the exact order of source file compilation. So the question arises,
> to what degree is is it invalid to even glance at their
> Cmakelist.txt for overall ideas on how to do this. Considering that
> they are simply emitting the same build commands as build.pl (to
> which we already have license), I imagine we would have to code in a
> very similar manner even if done from scratch, i.e., use instances
> of add_custom_command to manually emit the same build.pl commands.
> There probably aren't that many ways to code that in cmake.
> Jack

Yep, I understand. That's why what you did could be considered imprudent ;) -- In any case, let's give C. a chance to solve this problem for you.

In case that does not work out and it makes things easier, I've attached another alternate makefile that I use to build this library. Converting this into cmake form is also not too hard.

 -Hal

> 
> 
> 
> On Fri, May 30, 2014 at 7:10 PM, Jack Howarth <
> howarth.mailing.lists at gmail.com > wrote:
> 
> 
> 
> Hal,
> Even if that is problematic, starting over is fairly
> straight-forward. Their CMakelists.txt is simply a directly
> repetition of the commands emitted from the build as done by
> build.pl . So if they are difficult about it, just take a printout
> of the output for the current build with 'make compiler=clang" and
> code the Cmakelist.txt from that. If you look carefully, you will
> see that they are replicating this down to the exact order of the
> parameters on the compiler calls. It is very difficult to see how
> that could be intellectual property in any fashion since replicating
> the output of the build.pl currently in llvm.org 's openmp results
> in the same ordering. Note that their files are only a crude
> starting point and nowhere near what we will need for llvm.
> Jack
> 
> 
> 
> 
> 
> On Fri, May 30, 2014 at 6:40 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> Jack,
> 
> Before you go too far with this, do we have Pathscale's explicit
> contribution of their build files? (I've cc'd C. Bergstrom so that
> he can comment directly).
> 
> Thanks,
> Hal
> 
> 
> 
> ----- Original Message -----
> > From: "Jack Howarth" < howarth.mailing.lists at gmail.com >
> > To: openmp-dev at dcs-maillist2.engr.illinois.edu
> > Sent: Friday, May 30, 2014 5:28:33 PM
> > Subject: [Openmp-dev] (no subject)
> > 
> > 
> > 
> > Attached is a first pass at modifying the cmakefiles from
> > https://github.com/pathscale/openmprtl/blob/master/itt/libomp_oss
> > to
> > build openmp. I noticed that the existing build.pl doesn't actually
> > build a fat shared library on darwin. The attached changes can does
> > this in an indirect fashion with…
> > 
> > 
> > % cd runtime
> > % mkdir build_32
> > % cd build_32
> > % cmake -DARCH="32" ..
> > % make VERBOSE=1
> > % cd ..
> > % mkdir build_32e
> > % cmake -DARCH="32e" ..
> > % make VERBOSE=1
> > % cd ..
> > % lipo ./build_32/src/libiomp5.dylib ./build_32e/src/libiomp5.dylib
> > -create -o libiomp5.dylib
> > % file libiomp5.dylib
> > 
> > libiomp5.dylib: Mach-O universal binary with 2 architectures
> > libiomp5.dylib (for architecture x86_64): Mach-O 64-bit dynamically
> > linked shared library x86_64
> > libiomp5.dylib (for architecture i386): Mach-O dynamically linked
> > shared library i386
> > 
> > 
> > Normally we could do this in cmake by passing '-arch i386 -arch
> > x86_64' but use of assembly code in the build gums that up.
> > _______________________________________________
> > Openmp-dev mailing list
> > Openmp-dev at dcs-maillist2.engr.illinois.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/openmp-dev
> > 
> 
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
> 
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile.bgq
Type: text/x-makefile
Size: 2556 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20140530/7945b303/attachment.bin>