Bug 470830 - Review Request: open64 - The Open64 compiler suite (C, C++, Fortran)
Review Request: open64 - The Open64 compiler suite (C, C++, Fortran)
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dominik 'Rathann' Mierzejewski
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-11-10 10:09 EST by Susi Lehtola
Modified: 2011-11-12 08:47 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-01-15 14:56:40 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Susi Lehtola 2008-11-10 10:09:22 EST
Spec URL: http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec

SRPM URL:
http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2-1.el5.src.rpm

Description:

Open64 is a set of C, C++ and Fortran compilers. 

Open64 is the final result of research contributions from a number of compiler 
groups around the world. Formerly known as Pro64, Open64 was initially created 
by SGI and licensed under the GNU Public License (GPL). It was derived from 
SGI's MIPSPro compiler. 

Open64 also derives from work done by Intel Corp, in conjunction with the 
Chinese Academy of Sciences. They created the Open Research Compiler (ORC), 
a specially modified version of Open64 with custom modifications for 
researchers. These changes were later folded back into the main Open64 source 
tree in 2005. 


rpmlint output:
open64.x86_64: W: no-documentation
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/32/libstdc++.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/libgcc.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/libffio.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/32/libmv.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/32/libopenmp.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/libmv.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/32/libfortran.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/libopenmp.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/32/libgcc.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/32/libinstr.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/libstdc++.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/libfortran.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/32/libffio.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2/libinstr.a
open64-debuginfo.x86_64: E: script-without-shebang /usr/src/debug/open64-4.2-0/osprey/crayf90/sgi/cwh_types.i
../../SPECS/open64.spec:51: W: rpm-buildroot-usage %build export TOOLROOT=%{buildroot}/usr
../../SPECS/open64.spec:73: E: hardcoded-library-path in /usr/lib/gcc-lib/*
2 packages and 1 specfiles checked; 2 errors, 16 warnings.

devel-file-in-non-devel-package warnings also come with gcc, so that shouldn't be a problem.
script-without-shebang affects debuginfo package, no problem.
rpm-buildroot-usage is not a problem.
hardcoded-library-path warning is erroneous. Also gcc installs in /usr/lib/gcc-lib/ .
Comment 1 Jason Tibbitts 2008-11-10 12:48:27 EST
Unless I'm mistaken, gcc hasn't used /usr/lib/gcc-lib since 2.96.  Unless you're going to have a dependency on compat-libgcc-296, this package will leave /usr/lib/gcc-lib unowned.

Current gcc seems to use /usr/lib/gcc, even on x86_64.
Comment 2 Jason Tibbitts 2008-11-10 13:07:19 EST
A koji build has failed:
  http://koji.fedoraproject.org/koji/taskinfo?taskID=924836
Looks like you're missing a build dependency on csh.  Have you been able to build this package in mock or koji?

Are you sure this works on PPC?  I don't see any mention of PPC on the upstream web pages.  I doubt it works on ARM, Sparc or Alpha, either.  You will almost certainly need an ExcludeArch: or ExclusiveArch: statement.
Comment 3 Susi Lehtola 2008-11-10 14:52:43 EST
Thanks, noted and changed. Added reqs: gcc to fix problem with dir ownership. 

I was just going to fix the arch problem :)

Now the package builds in mock, had to add a few BRs.

http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec
http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2-2.fc9.src.rpm
Comment 4 Susi Lehtola 2008-11-10 16:30:36 EST
(In reply to comment #3)
> Thanks, noted and changed. Added reqs: gcc to fix problem with dir ownership. 
> 
> I was just going to fix the arch problem :)
> 
> Now the package builds in mock, had to add a few BRs.

More patches to fix change of library locations.

http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec
http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2-3.fc9.src.rpm
Comment 5 Susi Lehtola 2008-11-11 03:39:25 EST
Hmm, it seems that the compiled RPM doesn't really work on Fedora 9; in RHEL 5 it works fine. The binary RPM from open64.net works fine on Fedora 9...

I did have to do quite a bit of patching to the header files to get open64 to build in Fedora 9, since g++ 4.3 is stricter than g++ 4.2 which is in RHEL 5.

GCC 4.3 isn't listed as a supported compiler, 4.2 is. Too bad there's just 4.3 and 3.4 in Fedora - 4.3 is too new and 3.4 is too old, since one needs gfortran to compile the Fortran frontend.
Comment 6 Susi Lehtola 2008-11-11 04:00:49 EST
Or, I could compile open64 with itself by including the binary release in the srpm which would then be used to compile the sources.
Comment 7 Susi Lehtola 2008-11-11 09:32:30 EST
(In reply to comment #5)
> Hmm, it seems that the compiled RPM doesn't really work on Fedora 9; in RHEL 5
> it works fine. The binary RPM from open64.net works fine on Fedora 9...

Also the RPM compiled in RHEL 5 works fine in Fedora 9, so the problem is indeed with gcc 4.3.

I had a look at compiling open64 with the binary release of open64, but couldn't get it to work on Fedora 9.

The package could be restrained to EPEL, since it doesn't work on Fedora 9.
Comment 8 Jason Tibbitts 2008-11-11 10:22:12 EST
This package has to make it into rawhide in any case, so it needs to work on Fedora.

It is not unheard of for a package to include a binary copy once to do the initial bootstrapping; immediately after it is built, you remove the binary code and use the existing package to build the next one.  Take a look at the specfile for the fpc package and the "useprebuiltcompiler" define.

Still, it would perhaps be even better if the issues with gcc 4.3 were better understood before going that route.
Comment 9 Susi Lehtola 2008-11-13 01:56:08 EST
OK. Now I get it to build and work in mock for Fedora 9 x86_64 using open64 itself as compiler.

http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec
http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2-4.fc9.src.rpm
Comment 10 Susi Lehtola 2008-11-13 16:23:48 EST
(In reply to comment #9)
> OK. Now I get it to build and work in mock for Fedora 9 x86_64 using open64
> itself as compiler.
> 
> http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec
> http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2-4.fc9.src.rpm

Switched to RPM versions of prebuilt compiler, since the i386 binaries aren't available as tar files for some reason and the build fails.

Now the only problem is that mock refuses to build the srpm in 64-bit distros (except F9 works well!), due to

ERROR: Bad build req: No Package Found for /lib/ld-linux.so.2. Exiting.

However this file is required for the binary compilers (yes, the x86_64 binary is 32-bit also). If one leaves it out one gets

sh: /builddir/build/BUILD/open64-4.2-0/opt/open64/bin/opencc: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory


I'm not sure whether this is a bug in mock, I'm asking the fedora-packaging list.
Comment 12 Susi Lehtola 2008-11-13 16:25:07 EST
And it builds fine in rawhide x86_64 now, it just doesn't build on EPEL or Fedora 8 since mock can't find the buildreq.
Comment 13 Susi Lehtola 2008-11-13 16:56:22 EST
Still, in koji it doesn't seem to have any problems to build for x86_64..
http://koji.fedoraproject.org/koji/taskinfo?taskID=932345

Anyway, the compile seems to be working now on all distros and platforms.
Comment 14 Susi Lehtola 2008-11-26 13:30:35 EST
Changed optimization memory limit, path preference and summary.

http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec
http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2-6.fc9.src.rpm
Comment 15 Susi Lehtola 2008-12-12 11:54:07 EST
Updated to 4.2.1.
http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec
http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2.1-1.fc10.src.rpm


rpmlint output:
open64.src:136: E: hardcoded-library-path in /usr/lib/gcc-lib
open64.x86_64: W: no-documentation
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libopenmp.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libfortran.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libinstr.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libgcc.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libstdc++.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libopenmp.a
open64.x86_64: E: standard-dir-owned-by-package /usr/lib/gcc-lib
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libfortran.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libgcc.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libffio.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libinstr.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libffio.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libmv.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libstdc++.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libmv.a
3 packages and 0 specfiles checked; 2 errors, 15 warnings.
Comment 16 Susi Lehtola 2009-01-05 11:16:55 EST
Spec: http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec

SRPM: 
http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2.1-4.fc10.src.rpm

Koji scratch build:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1032744

Changes:
- Fix documentation encodings.
- Include documentation.
- Add patch to disable DevWarns.
- Add patches to enable linking to pthread library.
- Add patch to enable use of RPM_OPT_FLAGS in gcc wrapper.
- Enable parallel make.

rpmlint output:
open64.src:137: E: hardcoded-library-path in /usr/lib/gcc-lib
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libopenmp.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libfortran.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libinstr.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libgcc.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libstdc++.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libopenmp.a
open64.x86_64: E: standard-dir-owned-by-package /usr/lib/gcc-lib
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libfortran.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libgcc.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libffio.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libinstr.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libffio.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libmv.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libstdc++.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libmv.a
3 packages and 0 specfiles checked; 2 errors, 14 warnings.

None of these is a problem, since gcc has the same kinds of devel file warnings and /usr/lib/gcc-lib is not used anymore by other packages.
Comment 17 Susi Lehtola 2009-02-05 09:40:22 EST
Disabled BUILD_OPTIMIZE=DEBUG which produces unwanted debugging messages for developers of the compiler.

http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec
http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2.1-5.fc10.src.rpm
Comment 19 Dominik 'Rathann' Mierzejewski 2009-03-24 05:32:01 EDT
Taking review.
Comment 20 Susi Lehtola 2009-03-24 06:09:25 EDT
Thanks.

Fixed license tag, found other licenses using licensecheck.pl.

http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec
http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2.1-7.fc10.src.rpm
Comment 21 Dominik 'Rathann' Mierzejewski 2009-03-24 09:53:13 EDT
I'm told by the developers that it can be bootstrapped using gcc < 4.3. gcc-4.3 support is planned in the next release. I will try to make it buildable using compat-gcc-34 in the meantime.
Comment 22 Susi Lehtola 2009-03-24 10:02:16 EDT
(In reply to comment #21)
> I'm told by the developers that it can be bootstrapped using gcc < 4.3. gcc-4.3
> support is planned in the next release. I will try to make it buildable using
> compat-gcc-34 in the meantime.  

OK, if you get it working using gcc 3.4 then it will also run on RHEL 4, which would be nice.

gcc 4.3 support is not enough, since rawhide is already using gcc 4.4. I believe bootstrapping open64 with itself is the best solution (although the binary release doesn't work on RHEL 4).

Things would be easier if there were more versions of gcc usable in Fedora..
Comment 23 Dominik 'Rathann' Mierzejewski 2009-03-31 06:04:20 EDT
OK, I tackled this last week and here are the results (specfile + new patches):
http://rpm.greysector.net/fedora/open64/
It is now fully bootstrappable using compat-gcc-34(-c++).

I've also filed two bugs upstream:
https://bugs.open64.net/show_bug.cgi?id=526

https://bugs.open64.net/show_bug.cgi?id=527

Also I think you don't need to put licences other than GPLv2+ in the License: tag, because the others are compatible.
Comment 24 Susi Lehtola 2009-03-31 10:25:08 EDT
Hmm, I can't get the bootstrapping to work. It fails when it tries to build crayf90/sgi, i.e. the Fortran library. The linking against -lgfortran does not work (even though the library is there).

http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec
http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2.1-8.fc10.src.rpm

g++   -m64  -D_SGI_SOURCE -D_LANGUAGE_C_PLUS_PLUS -Wformat -funsigned-char -D__GNU_BUG_WORKAROUND -D_NOTHREADS       -DSGI_DIRS -Dlonglong -DSGI_MONGOOSE -DFRONT_END -DFRONT_F90 -D_PDGCS  -DUSE_STANDARD_TYPE
S -D __MIPS_AND_IA64_ELF_H -Dlinux -D__USE_BSD -D_GNU_SOURCE -D_LONGLONG -D_SVR4_SOURCE   -D_SGI_SGI -D_TARGET_MONGOOSE -D_SGI_WHIRLCONVERT -I../../../crayf90/fe90 -I../../../crayf90/sgi -I../../../common/co
m -I../../../common/util -I../../../common/com/x8664 -I. -I../../../include -I../../../linux/mfef90_includes -I../../../linux/include -I../../include/cmplrs   -DTARG_X8664 -D__STDC_LIMIT_MACROS -DKEY -DOSP_O
PT -DPATHSCALE_MERGE -DPSC_TO_OPEN64   -DSHARED_BUILD     -I../../include  -O2 -fno-strict-aliasing -D_MIPSEL -D_LONGLONG -D_MIPS_SZINT=32 -D_MIPS_SZPTR=64 -D_MIPS_SZLONG=64 -D_LP64 -MMD -o mfef95  config.o 
const.o controls.o dwarf_DST.o dwarf_DST_dump.o dwarf_DST_mem.o dwarf_DST_producer.o err_host.o f90_utils.o glob.o ir_bcom.o ir_bwrite.o ir_reader.o irbdata.o mtypes.o opcode.o opcode_core.o pu_info.o strtab
.o symtab.o symtab_verify.o ttype.o wn.o wn_map.o wn_pragmas.o wn_simp.o wn_util.o wutil.o  config_targ.o config_elf_targ.o targ_const.o targ_sim.o cwh_unimp.o cwh_addr.o cwh_auxst.o cwh_block.o cwh_data.o c
wh_directive.o cwh_dope.o cwh_dst.o cwh_expr.o cwh_intrin.o cwh_io.o cwh_mkdepend.o cwh_pdgcs.o cwh_preg.o cwh_types.o cwh_stab.o cwh_stmt.o cwh_stk.o decorate_utils.o f2c_abi_utils.o sgi_cmd_line.o path_int
rinsic_list.o make_depend.o    config_host.o config_platform.o                 compiler_build_date.o  -L./ ../../libcomutil/libcomutil.a       ../fe90/fe90.a ../../arith/arith.a ../../libcif/libcif.a  ../lib
f90sgi/libf90sgi.a -lm  -lpthread  -D_MIPSEL -lgfortran -m64 -lm 
/usr/bin/ld: cannot find -lgfortran
collect2: ld returned 1 exit status
make[4]: *** [mfef95] Error 1
Comment 25 Dominik 'Rathann' Mierzejewski 2009-03-31 13:56:04 EDT
Note that my specfile does not depend on gcc-gfortran. Please look at the diff between your specfile and the one I posted in detail.
Comment 26 Susi Lehtola 2009-03-31 14:06:06 EDT
(In reply to comment #25)
> Note that my specfile does not depend on gcc-gfortran. Please look at the diff
> between your specfile and the one I posted in detail.  

Yes, but even though I added the gfortran dependency, it still didn't work...
Comment 27 Dominik 'Rathann' Mierzejewski 2009-03-31 14:39:50 EDT
Because it WON'T work with gfortran, so don't add that dependency. As I said, what I posted built for me in mock on fedora-10-x86_64, so please attach the full log of your build.
Comment 28 Susi Lehtola 2009-03-31 17:49:29 EDT
Oh, you're right, the build works for F10 x86_64 without the gfortran dependency. It doesn't build on (mock) EPEL4 though, but maybe that's a lost cause.

These should work now.

http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec
http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2.1-8.fc10.src.rpm

PS. Why do you have the empty
%if %{bootstrapping}
%endif

in the setup phase? Was some patch supposed to be there? I left it in for the time being.
Comment 29 Dominik 'Rathann' Mierzejewski 2009-04-06 15:23:22 EDT
(In reply to comment #28)
> Oh, you're right, the build works for F10 x86_64 without the gfortran
> dependency. It doesn't build on (mock) EPEL4 though, but maybe that's a lost
> cause.

We can worry about that later. ;)

> These should work now.
> 
> http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec
> http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2.1-8.fc10.src.rpm
> 
> PS. Why do you have the empty
> %if %{bootstrapping}
> %endif
> 
> in the setup phase? Was some patch supposed to be there? I left it in for the
> time being.  

Yes, there was a patch, but it turned out to be necessary in both bootstrapping and non-bootstrapping case.

Note that you might be able to use gcc-4.1 on EL-5 so the patch (and the accompanying gcc34 override) will not be necessary then.

I assume this is now ready for full review.
Comment 30 Susi Lehtola 2009-04-06 15:48:54 EDT
(In reply to comment #29)
> > PS. Why do you have the empty
> > %if %{bootstrapping}
> > %endif
> > 
> > in the setup phase? Was some patch supposed to be there? I left it in for the
> > time being.  
> 
> Yes, there was a patch, but it turned out to be necessary in both bootstrapping
> and non-bootstrapping case.

OK, I'll remove it later.

> Note that you might be able to use gcc-4.1 on EL-5 so the patch (and the
> accompanying gcc34 override) will not be necessary then.

Yes, maybe. I think I tried it before, but it didn't work. But that can be worked out later (in koji, if need be).
 
> I assume this is now ready for full review.  

Yes, please.
Comment 31 Orion Poplawski 2009-07-09 14:25:57 EDT
Anyone know how different this is from AMD's x86 Open64 Compiler?

http://developer.amd.com/cpu/open64/Pages/default.aspx
Comment 32 Susi Lehtola 2009-07-09 15:16:33 EDT
(In reply to comment #31)
> Anyone know how different this is from AMD's x86 Open64 Compiler?

Well, AMD's version seems to be newer (4.2.2.1, assuming they use the same numbering as open64.net) and it includes the (non-free) ACML libraries in binary form:
" The libacml_mv runtime library, used automatically for certain optimizations,
 is provided in binary form at this time. The Software License Agreement is
 detailed in the file LICENSE-LIBACML_MV."
Comment 33 Susi Lehtola 2009-07-09 15:43:59 EDT
It seems the AMD version is available in the open64 svn server:

http://svn.open64.net/listing.php?repname=Open64&path=%2Fbranches%2Fx86_open64-4.2.2%2F#path_branches_x86_open64-4.2.2_

so I guess they're not very separate forks. Probably the AMD guys just have added AMD-specific optimizations (such as the aforementioned math library) to their version.
Comment 34 Orion Poplawski 2009-10-23 18:44:48 EDT
We seem stalled here.  Dominik, you still around?
Comment 35 Dominik 'Rathann' Mierzejewski 2009-10-25 19:15:37 EDT
Still here. I'll do the review soon.
Comment 36 Dominik 'Rathann' Mierzejewski 2009-11-08 16:44:22 EST
Full review:

open64.src: W: name-repeated-in-summary Open64
open64.x86_64: W: name-repeated-in-summary Open64
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libopenmp.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libfortran.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libinstr.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libgcc.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libstdc++.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libopenmp.a
open64.x86_64: E: standard-dir-owned-by-package /usr/lib/gcc-lib
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libfortran.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libgcc.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libffio.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libinstr.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libffio.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/libmv.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libstdc++.a
open64.x86_64: W: devel-file-in-non-devel-package /usr/lib/gcc-lib/x86_64-open64-linux/4.2.1/32/libmv.a

Summary could be improved not to repeat the name.
/usr/lib/gcc-lib ownership issue is I think bogus, because no package in Fedora owns it.
The other warnings can be ignored as this is a compiler.

Source is downloadable and MD5 hash matches.
73096667243fbfab605630b1aea380dd  open64-4.2.1-0.src.tar.bz2

Builds in mock/rawhide/x86_64.

Please ask upstream to include GPLv2 text in the next release tarball.

There's still an issue of included pre-built static libraries (find . -name "*.a" shows a bunch), but since this is a compiler, you can ask for an initial exception from FESCo, per https://fedoraproject.org/wiki/Packaging/Guidelines#No_inclusion_of_pre-built_binaries_or_libraries . Also I wasn't able to build open64 again using itself in rawhide mock.
Comment 37 Susi Lehtola 2009-11-08 16:57:00 EST
Additionally, it seems I have to disable the automatic provide and require generation of RPM due to some generic names such as libstdc++, libgcc and libfortran provided by open64.
Comment 38 Susi Lehtola 2010-01-15 14:56:40 EST
Ugh. I have had a new look at the package once again, and the compiler doesn't work in Fedora 12 (some problem with C++ headers I think). There's no new release that would address the compatibility problem; anyway upstream seems to lag quite a bit behind gcc releases.

All in all, I think I'll give up - maintaining this package would be a huge workload, since it seems to break down in each new release of Fedora.

Thanks for your time, closing as CANTFIX.

Note You need to log in before you can comment on or make changes to this bug.