Bug 470830

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.

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.

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

(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

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.

Or, I could compile open64 with itself by including the binary release in the srpm which would then be used to compile the sources.

(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.

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.

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

(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.

Oh, and the links

http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64.spec
http://theory.physics.helsinki.fi/~jzlehtol/rpms/open64-4.2-5.fc9.src.rpm

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.

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.

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

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.

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.

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

Cleaned up patches and spec file.

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

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

Taking review.

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

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.

(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..

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.

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

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.

(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...

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.

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.

(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.

(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.

Anyone know how different this is from AMD's x86 Open64 Compiler?

http://developer.amd.com/cpu/open64/Pages/default.aspx

(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."

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.

We seem stalled here.  Dominik, you still around?

Still here. I'll do the review soon.

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.

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.

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.