You are not logged in.
Hi,
I'm the creator of the icc (Intel's C/C++ compiler) and ifort (Intel's Fortran compiler) PKGBUILD in AUR. Each packages is downloadable as RPM. Basicaly I rpmextract.sh them in the PKGBUILD.
In the new version (11.0), they changed the directory structure. Instead of having a separate directory for each compiler, they are now installed in the same directory. Because of that, common files between the compilers, which are included in each rpms, are going in the same place on the filesystem. Installing the first compiler with pacman then works, but the second one can't be installed because the common files already exists.
My question is, how does RPM manages that? I though RPM was really not that powerful and that it would fail like pacman.
Maybe I'm missing something for the installation... Somebody has something to suggest?
Thanx
AUR links:
http://aur.archlinux.org/packages.php?ID=2252
http://aur.archlinux.org/packages.php?ID=2251
Offline
Well... create a third PKGBUILD with the common files in it?
Offline
Yeah maybe...
I'm just puzzled how RPM manages that...
Offline
Hum... After investigating, rpm might be called with "-U --replacefiles --force --nodeps"...
Offline
Hum... After investigating, rpm might be called with "-U --replacefiles --force --nodeps"...
This has the same negative disadvantages as you will do it the same with pacman. I don't think this is the favorite way and a rpm package can include scripts in nearly the same way as a install file can be used with a PKGBUILD but i don't think that you will see this files it if you use rpmextract.sh to extract it.
Seconds before you wrote this lines i run a "makepkg -g" to get the files and i can extract the the 5 rpm's from the data directory inside of this 2 archives in the same directory without an error. Do you speak from other rpms or can you give the link to the rpms from what you speak?
EDIT: Okay, could it be that you mean the file intel-iidb101018-10.1.018-1.i386.rpm is included in both archives? For rpm this doesn't matter because if you do a "rpm -Uvh *.rpm" and one of them is installed you get a "package xyz is already installed" but the other get installed.
Last edited by attila (2008-11-11 21:35:20)
Offline
I meant a conflict between icc and ifort.
big_gie wrote:Hum... After investigating, rpm might be called with "-U --replacefiles --force --nodeps"...
This has the same negative disadvantages as you will do it the same with pacman. I don't think this is the favorite way and a rpm package can include scripts in nearly the same way as a install file can be used with a PKGBUILD but i don't think that you will see this files it if you use rpmextract.sh to extract it.
If the installation process (intel's own install script) really launch rpm with these options, it would be the same as running pacman with "-Sf" and overwrite the already installed files. Removing one the two packages will result as the other one failing to run.
Seconds before you wrote this lines i run a "makepkg -g" to get the files and i can extract the the 5 rpm's from the data directory inside of this 2 archives in the same directory without an error. Do you speak from other rpms or can you give the link to the rpms from what you speak?
Yeah... The rpms from _one_ .tgz don't conflicts with each other. What is conflicting is installing one of icc or ifort and then installing the other one.
I see two ways to correct that:
1) Install each one ine their own directories. You end up with duplicate files and you need to make sure it does not break the installation (shared libs and others...)
2) Doing a 3rd package containing the conflicting files, and strip these files from the compilers pkg. I'm going this way right now...
Offline
I see two ways to correct that:
1) Install each one ine their own directories. You end up with duplicate files and you need to make sure it does not break the installation (shared libs and others...)
2) Doing a 3rd package containing the conflicting files, and strip these files from the compilers pkg. I'm going this way right now...
Yes the second way is my favorite too but as i wrote in my EDIT lines before could it be that the problem is that in both archives the file intel-iidb101018-10.1.018-1.i386.rpm is included? So you can make a 3rd package only with the content of this file and delete this file in the other 2 PKGBUILDs before you run extract.sh.
But this only a suggestion and i'm sure that you will have a better idea because your PKGBUILDs be very much more complicated than one of mine.
Offline
Ok I did not see your edit
No this file is the debugger, which I am not installing (at the moment...) Duplicated files comes really from "intel-cprof110069e-11.0-1.x86_64.rpm" (fortran compiler) and "intel-cproc110069e-11.0-1.x86_64.rpm" (c/c++ compiler) Note the bolded "f" and "c" as the only difference in the filename...
Here is a list of duplicated files:
Documentation/cluster_omp/docs/UsersGuide.pdf
Documentation/cluster_omp/examples/C/Makefile
Documentation/cluster_omp/examples/C/README
Documentation/cluster_omp/examples/C/hello.c
Documentation/cluster_omp/examples/C/kmp_cluster.ini
Documentation/cluster_omp/examples/C/md.c
Documentation/cluster_omp/examples/C/mpd.hosts
Documentation/cluster_omp/examples/Fortran/Makefile
Documentation/cluster_omp/examples/Fortran/README
Documentation/cluster_omp/examples/Fortran/hello.f
Documentation/cluster_omp/examples/Fortran/kmp_cluster.ini
Documentation/cluster_omp/examples/Fortran/md.f
Documentation/cluster_omp/tools/README.forecaster
Documentation/cluster_omp/tools/README.getlatency
Documentation/cluster_omp/tools/README.segvprof
Documentation/cluster_omp/tools/clomp_forecaster.pl
Documentation/cluster_omp/tools/clomp_getlatency.pl
Documentation/cluster_omp/tools/segvprof.pl
bin/ARCHDIR/codecov
bin/ARCHDIR/map_opts
bin/ARCHDIR/profdcg
bin/ARCHDIR/profmerge
bin/ARCHDIR/proforder
bin/ARCHDIR/tselect
bin/ARCHDIR/xiar
bin/ARCHDIR/xild
include/ARCHDIR/kmp_remote_memory.h
include/ARCHDIR/kmp_sharable.h
lib/ARCHDIR/codecov_libFNP.so
lib/ARCHDIR/crtclusterbegin.o
lib/ARCHDIR/crtclusterend.o
lib/ARCHDIR/init.o
lib/ARCHDIR/libclompc.so
lib/ARCHDIR/libclusterguide.so
lib/ARCHDIR/libclusterguide_stats.so
lib/ARCHDIR/libcxaguard.a
lib/ARCHDIR/libcxaguard.so
lib/ARCHDIR/libcxaguard.so.5
lib/ARCHDIR/libdecimal.a
lib/ARCHDIR/libguide.a
lib/ARCHDIR/libguide.so
lib/ARCHDIR/libguide_stats.a
lib/ARCHDIR/libguide_stats.so
lib/ARCHDIR/libimf.a
lib/ARCHDIR/libimf.so
lib/ARCHDIR/libintlc.so
lib/ARCHDIR/libintlc.so.5
lib/ARCHDIR/libiomp5.a
lib/ARCHDIR/libiomp5.so
lib/ARCHDIR/libiompprof5.a
lib/ARCHDIR/libiompprof5.so
lib/ARCHDIR/libiompstubs5.a
lib/ARCHDIR/libiompstubs5.so
lib/ARCHDIR/libipgo.a
lib/ARCHDIR/libirc.a
lib/ARCHDIR/libirc.so
lib/ARCHDIR/libirc_s.a
lib/ARCHDIR/libomp_db.so
lib/ARCHDIR/libompstub.a
lib/ARCHDIR/libompstub.so
lib/ARCHDIR/libsvml.a
lib/ARCHDIR/libsvml.so
lib/ARCHDIR/locale/en_US/irc_msg.cat
lib/ARCHDIR/locale/en_US/libclusterguide.cat
lib/ARCHDIR/locale/en_US/libguide.cat
lib/ARCHDIR/locale/en_US/libiomp5.cat
lib/ARCHDIR/locale/en_US/libm.cat
lib/ARCHDIR/locale/ja_JP/irc_msg.cat
lib/ARCHDIR/locale/ja_JP/libclusterguide.cat
lib/ARCHDIR/locale/ja_JP/libguide.cat
lib/ARCHDIR/locale/ja_JP/libiomp5.cat
lib/ARCHDIR/locale/ja_JP/libm.cat
lib/ARCHDIR/sharable_init.o
lib/ARCHDIR/tselect_libFNP.so
man/man1/codecov.1
man/man1/tselect.1
and also the EULA.htm, included by me.
I created another pkg to include these, and icc and ifort depends on it.
I just finished the PKGBUILDs. I will upload them shortly.
But this only a suggestion and i'm sure that you will have a better idea because your PKGBUILDs be very much more complicated than one of mine.
It may seems complicated... But I did that because I'm lazy Both icc and ifort are the exact same PKGBUILD except for small details at the top. That way, I only have to maintain one. Also, I had to "mimic" what the installer script was doing and modify a couple of config files to point to the right place.
Don't forget "Simplicity is the ultimate sophistication" But sometimes, you need something more powerful...
Offline
Ok I did not see your edit
No problem because i'm confused about how this rpms could be installed together.
No this file is the debugger, which I am not installing (at the moment...) Duplicated files comes really from "intel-cprof110069e-11.0-1.x86_64.rpm" (fortran compiler) and "intel-cproc110069e-11.0-1.x86_64.rpm" (c/c++ compiler) Note the bolded "f" and "c" as the only difference in the filename...
Ah okay ... and the most problem was that i try it only with former 10.1.018.
I think i must try to install this 2 rpms in my vm with opensuse to see how this could be work or perhaps one of the scripts inside handle this situation because you have to be root to run them. Still again this looks very strange and from my view it is not very funny that intel offers this mixed thing with scripts and rpms inside of the archiv instead of offering only rpms.
Offline
Ok so I created a third PKGBUILD finaly and bump the two other's version:
ifort v11.0.069: http://aur.archlinux.org/packages.php?ID=2251
icc v11.0.069: http://aur.archlinux.org/packages.php?ID=2252
intel-compilers-common v11.0.069: http://aur.archlinux.org/packages.php?ID=21399
Thanx for the suggestion
Offline
Okay, i download your new packages to have it easier to get the tar files. Than i give the rpms inside of it a try in a vm with opensuse and a "rpm -Uvh *.rpm" complains about file which be in the same package which is not realy a wonder. So for me the result is that the package maintainer from intel do a bad job, you choose the right decision and gratulation for your fantastic work.
Offline
thanx
Offline
Okay, i download your new packages to have it easier to get the tar files. Than i give the rpms inside of it a try in a vm with opensuse and a "rpm -Uvh *.rpm" complains about file which be in the same package which is not realy a wonder. So for me the result is that the package maintainer from intel do a bad job, you choose the right decision and gratulation for your fantastic work.
lol, so it handles it the same way as pacman "OH CRAP! CONFLICT!"
Offline
lol, so it handles it the same way as pacman "OH CRAP! CONFLICT!"
hehe... it does'nt even check for conclicts... The script launch rpm (the program) with --force so it just overwrites everything!!
Offline
lol, so it handles it the same way as pacman "OH CRAP! CONFLICT!"
Yes but this is not a wonder because i don't think there is a package program which default is to overwrites files without a warning.
hehe... it does'nt even check for conclicts... The script launch rpm (the program) with --force so it just overwrites everything!!
Oh, i overseen this ... this is incomprehensible. I was still wondering about this idea to use a script to install rpm packages but now i know why.
Offline
I'm confused...
I want only the intel c compiler. Do I need to install also the intel-compilers-common?
Inthe AUR page of icc I don't see intel-compilers-common dependency, while I see it only in the intel fortran compiler AUR page.
Offline
I don't use intel's fortran compiler anymore, so the pkgbuild for it is old. But the icc's works. So forget about intel-compilers common, its not needed anymore (by icc at least)
Offline
Ok, thanks
Offline
I install icc. It seems everything ok, no error messages appear. if I ask
pacman -Q icc
I can see my version installed.
But when I launch Code::Blocks, my IDE, it doesn't recognised intel compiler. Do you the wizard that appears the first time you launch an IDE like Code::Blocks? Well, that wizard recognised GNU gcc but not intel c compiler. Do you know the reason why this happens?
Offline
This is something about Code::Blocks, not icc. You need to ask Code::Blocks' developpers to support icc.
Or else, just use your own makefiles.
Offline
Code::Blocks do support icc. When you launch it for the first time, it shows a list of supported compilers (among which you can find gcc and icc) each of which with a label showing if it was detected or not. In my case, Code::Blocks detects only gcc.
I will investigate.
Thanks for your help.
Offline
Ok, Ill check it out too.
Offline