[Openmp-dev] (no subject)

[Hal Finkel]

Jack,

No, I based my makefile on a manual examination of the various .mk files in the runtime/src directory (+ some trial and error). It is for a port of the library to a ppc64-based system, so you'll need to make some changes (like adding back the asm file) to make it work on Darwin.

 -Hal

----- 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 7:04:59 PM
> Subject: Re: [Openmp-dev] (no subject)
> 
> 
> Hal,
> Did you base your Makefile on the behavior of build.pl from 'make
> compiler=gcc'? On darwin, I find that the exact build as replicated
> from the behavior of build.pl using 'make compiler=clang' produces a
> different object file list….
> 
> 
> 
> --- Makefile.bgq 2014-05-30 19:59:16.000000000 -0400
> +++ Makefile.jwh 2014-05-30 20:01:08.000000000 -0400
> @@ -7,10 +7,10 @@
> 
> CPPFLAGS = ${FEATURE_FLAGS} -D__float128='long double'
> 
> -CC = powerpc64-bgq-linux-gcc
> -CXX = powerpc64-bgq-linux-g++
> +CC = clang
> +CXX = clang++
> 
> -all: build/libiomp5.a build/libiomp5.so
> +all: build/libiomp5.a build/libiomp5.dylib
> 
> build/.dir:
> mkdir -p build
> @@ -28,6 +28,7 @@
> ${CC} -x c++ -c ${CPPFLAGS} -g -O3 -Isrc -Ibuild -o $@ $<
> 
> OBJS = build/kmp_alloc.o \
> + build/kmp_affinity.o \
> build/kmp_atomic.o \
> build/kmp_cancel.o \
> build/kmp_csupport.o \
> @@ -37,8 +38,8 @@
> build/kmp_error.o \
> build/kmp_ftn_cdecl.o \
> build/kmp_ftn_extra.o \
> - build/kmp_ftn_stdcall.o \
> build/kmp_global.o \
> + build/kmp_gsupport.o \
> build/kmp_i18n.o \
> build/kmp_io.o \
> build/kmp_itt.o \
> @@ -53,7 +54,8 @@
> build/kmp_utility.o \
> build/kmp_version.o \
> build/kmp_lock.o \
> - build/z_Linux_util.o
> + build/z_Linux_util.o \
> + build/ittnotify_static.o
> 
> BGSYS_FLOOR=$(shell readlink /bgsys/drivers/ppcfloor)
> build/libiomp5.so: $(OBJS)
> [prrg4:~/llvm-svn/openmp-3.5.0/runtime] howarth%
> 
> 
> 
> 
> 
> On Fri, May 30, 2014 at 7:30 PM, Hal Finkel < hfinkel at anl.gov >
> wrote:
> 
> 
> 
> ----- 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
> 
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory