[Openmp-dev] (no subject)
Jack Howarth
howarth.mailing.lists at gmail.com
Fri May 30 17:04:59 PDT 2014
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20140530/baf9e05b/attachment.html>
More information about the Openmp-dev
mailing list