Mailing List Archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Brian,
Brian Harring schrieb:
> Unless someone steps up, the intel compiler toolchain
> packages dev-lang/icc (intel cc) and dev-lang/ifc (intel fortran
> compiler) are prime candidates for removal from the tree; open bugs,
> primary maintainer is retired, and no devs have moved in to pick up the
> packages, let along touched the changeslogs in around a year.
>
> So, any takers?
> ~brian

In case there are no security Bugs, i'd like to ask you to leave them in
for the time being, I'm working on getting the latest versions (8.0/8.1)
of ifort (how it is now known) and icc into the tree. The only problem
are my time constraints atm :-/. Though I have ebuilds ready, it will
still take some time to remove some minor itches before I'd commit them.

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCgFJXaVNL8NrtU6IRAlISAJ0Q6JrytYC08+gKN3/PhsSw4WG7xwCgk3E6
/VpqlPPXHK36vpfQ8zjatoQ=
=gJtG
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Danny van Dyk wrote:
| Hi Brian,
| Brian Harring schrieb:
|
|>>Unless someone steps up, the intel compiler toolchain
|>>packages dev-lang/icc (intel cc) and dev-lang/ifc (intel fortran
|>>compiler) are prime candidates for removal from the tree; open bugs,
|>>primary maintainer is retired, and no devs have moved in to pick up the
|>>packages, let along touched the changeslogs in around a year.
|>>
|>>So, any takers?
|>>~brian
|
|
| In case there are no security Bugs, i'd like to ask you to leave them in
| for the time being, I'm working on getting the latest versions (8.0/8.1)
| of ifort (how it is now known) and icc into the tree. The only problem
| are my time constraints atm :-/. Though I have ebuilds ready, it will
| still take some time to remove some minor itches before I'd commit them.
|
| Danny

Please contact me in case you need any help to test the ebuilds. I think
these ebuilds are far too important to be deleted from the portage tree.
These tools are crucial for my (and other people's) job.
Also add sci-libs/mkl to this list.

Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCgO9YQTaBhxBS2xERAupzAJ9czZC93O+inKTiNBdk2xVnhC3yIACfUeYO
Mg6HX5rhO+AWdjXTAsk1FeQ=
=t9MT
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Tom,

> |>>Unless someone steps up, the intel compiler toolchain
> |>>packages dev-lang/icc (intel cc) and dev-lang/ifc (intel fortran
> |>>compiler) are prime candidates for removal from the tree; open bugs,
> |>>primary maintainer is retired, and no devs have moved in to pick up the
> |>>packages, let along touched the changeslogs in around a year.

> | In case there are no security Bugs, i'd like to ask you to leave them in
> | for the time being, I'm working on getting the latest versions (8.0/8.1)
> | of ifort (how it is now known) and icc into the tree. The only problem
> | are my time constraints atm :-/. Though I have ebuilds ready, it will
> | still take some time to remove some minor itches before I'd commit them.
>
> Please contact me in case you need any help to test the ebuilds. I think
> these ebuilds are far too important to be deleted from the portage tree.
> These tools are crucial for my (and other people's) job.
> Also add sci-libs/mkl to this list.

(CCing gentoo-sci@l.g.o, as i guess i'll thus reach the majority of icc
dependant Gentoo users)

I'll appreciate any help I can get on that :-)

Some of my thoughts on current problems (w/o having searched bugzilla yet!)

dev-lang/icc and dev-lang/ifc
* No support for icc/ifort in (g)cc-config.

* Different naming schemes for distributed packages. A friend of mine
has a l_intel_cc_pu_${PV}.tar.gz for his academic work. I got a
l_intel_cc_p_${PV}.tar.gz from Intel's premier support... go
figure... :-/ Is it valid to specify
SRC_URI="|| ( file1 file2 )"
in an ebuild ? Or can we use wildcards in SRC_URI?
* icc depends on gcc's libstdc++, so changing your gcc version affects
icc and can even break it.

sci-libs/mkl
* integration in current virtual/{blas,lapack} scheme is missing (but
in the works for app-admin/eclectic)
* some lapack functions have uncommon naming scheme ('z' prefix where
'd' would be expected.)
* distributed via binary installer that has a rpm file as payload which
can't be extracted. Up to now, i always have to run the installer
once to obtain the rpm file.

all of the above
* New versions need fetch restrictions turned on. This means for all
users of the old (and free as in beer) versions some nastiness for
the next update. Also, the old versions would be removed:
Slotting? if yes, based on what?

icc/ifc use flags:
* These are scary. Using a different compiler should not be achieved
by setting a useflag, neither local nor global one.

I'd like to have some feedback on these problems :-)

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCgPgXaVNL8NrtU6IRAmb2AJ4ryP18mNxTUcS/WdfHNi+LDYsXlwCgplGz
dUZIpvoc+FP0gLXgzaaF/aU=
=7/T2
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

On Tue, 2005-05-10 at 20:06 +0200, Danny van Dyk wrote:
> icc/ifc use flags:
> * These are scary. Using a different compiler should not be achieved
> by setting a useflag, neither local nor global one.

You are correct. However, it might be necessary to patch something that
won't compile with icc, but does compile with gcc. I think this is the
primary reason for the icc USE flag.

--
Chris Gianelloni
Release Engineering - Strategic Lead/QA Manager
Games - Developer
Gentoo Linux

On Tuesday 10 May 2005 22:11, Chris Gianelloni wrote:
> You are correct. However, it might be necessary to patch something that
> won't compile with icc, but does compile with gcc. I think this is the
> primary reason for the icc USE flag.
Isn't tc-* functions there also for this?
And anyway, there can be patches which makes something work both with icc and
gcc.
When I worked a bit with icc, I found out that it was just stricter than gcc,
but all the changes needed to be done for icc was right also for gcc (and
usually stopped gcc from throw a warning on something).
Probably with gcc4 many of the errors are now shared by both compilers as it
turned up even more strict than before.

--
Diego "Flameeyes" Pettenò
Gentoo Developer (Gentoo/FreeBSD, Video, Gentoo/AMD64)

http://dev.gentoo.org/~flameeyes/

On Tue, May 10, 2005 at 04:11:48PM -0400, Chris Gianelloni wrote:
> On Tue, 2005-05-10 at 20:06 +0200, Danny van Dyk wrote:
> > icc/ifc use flags:
> > * These are scary. Using a different compiler should not be achieved
> > by setting a useflag, neither local nor global one.
>
> You are correct. However, it might be necessary to patch something that
> won't compile with icc, but does compile with gcc. I think this is the
> primary reason for the icc USE flag.
>

Yes, it is. As far as I know the icc USE flag doesn't actually change
your compiler anywhere (it shouldn't)

--
Jon Portnoy
avenj/irc.freenode.net
--
gentoo-dev@gentoo.org mailing list

On Tue, May 10, 2005 at 08:06:15PM +0200, Danny van Dyk wrote:
> Some of my thoughts on current problems (w/o having searched bugzilla yet!)
>
for dev-lang/icc-6.0-r1
l_cc_p_6.0.139.tar isn't fetchable

and for
dev-lang/icc-7.1.029
l_cc_pc_7.1.029.tar isn't fetchable

and....
dev-lang/ifc-6.0
l_fc_p_6.0.140.tar isn't fetchable.

These fetching failures are the only reason I even noticed xtv was
gone, and the ebuilds have begun collecting a fair amount of open bugs :)
~brian

On 5/10/05, Danny van Dyk <kugelfang@gentoo.org> wrote:

> * icc depends on gcc's libstdc++, so changing your gcc version affects
> icc and can even break it.

Hi,

icc version 8.1 can also use Intel's Dinkumware C++ library. It is
included with the compiler and can be accessed by the -cxxlib_icc
(IIRC) options. The default is to link with the GCC library though.

AFAIK Intel is removing this option for the upcoming version 9 of the
product so that it will depend on GCC being installed.

// Andreas

--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Harring schrieb:
> for dev-lang/icc-6.0-r1
> l_cc_p_6.0.139.tar isn't fetchable
>
> and for
> dev-lang/icc-7.1.029
> l_cc_pc_7.1.029.tar isn't fetchable
>
> and....
> dev-lang/ifc-6.0
> l_fc_p_6.0.140.tar isn't fetchable.

Fine, fine.... this means i can remove them as soon as i pout the new
versions in :-) I'm now going to package mask all of icc/ifc.
Thanks Brian!

> These fetching failures are the only reason I even noticed xtv was
> gone, and the ebuilds have begun collecting a fair amount of open bugs
I've only noticed around 10, are the probably even more ?

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCgb40aVNL8NrtU6IRAvCXAJsE42wpWJBiWJjzCMt0dNVDyfldsgCfeJwO
/uR0AdiBEsVEq/rALrqt1AA=
=lSBV
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

On Wed, May 11, 2005 at 10:11:32AM +0200, Danny van Dyk wrote:
> Fine, fine.... this means i can remove them as soon as i pout the new
> versions in :-) I'm now going to package mask all of icc/ifc.
Hmm. mm'kay, get cracking, they'll still get flagged in my script :)
>
> > These fetching failures are the only reason I even noticed xtv was
> > gone, and the ebuilds have begun collecting a fair amount of open bugs
> I've only noticed around 10, are the probably even more ?
Nope, that's probably about it. Just 10 bugs, with no updates for
about a year... :)
~brian
--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Harring wrote:
| Unless someone steps up, the intel compiler toolchain
| packages dev-lang/icc (intel cc) and dev-lang/ifc (intel fortran
| compiler) are prime candidates for removal from the tree; open bugs,
| primary maintainer is retired, and no devs have moved in to pick up the
| packages, let along touched the changeslogs in around a year.
|
| So, any takers?
| ~brian
re: ICC:

let me come back from my vacation (offcially 5/19/05) and i will look
into that, from previous bugs on boost when it wouldnt work with icc, i
know there would be too many upset users to just let it vanish

if anyone else is interested, i wont insist on taking it, just don't
think this is a package to even consider killing off

thanks

Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCgn5aUpKYMelfdYERAmsCAKCFJCkKWn2yMVec01PXsHamTnEGbQCfRTBU
UA9A0QVfJ1zPN7xiOuebKs4=
=Oc4r
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

Danny van Dyk wrote:
> Hi Brian,
> Brian Harring schrieb:
>
>>>Unless someone steps up, the intel compiler toolchain
>>>packages dev-lang/icc (intel cc) and dev-lang/ifc (intel fortran
>>>compiler) are prime candidates for removal from the tree; open bugs,
>>>primary maintainer is retired, and no devs have moved in to pick up the
>>>packages, let along touched the changeslogs in around a year.
>>>
>>>So, any takers?
>>>~brian
>
>
> In case there are no security Bugs, i'd like to ask you to leave them in
> for the time being, I'm working on getting the latest versions (8.0/8.1)
> of ifort (how it is now known) and icc into the tree. The only problem
> are my time constraints atm :-/. Though I have ebuilds ready, it will
> still take some time to remove some minor itches before I'd commit them.

Last time I started hacking on this, I was told to stop by the current
maintainer at the time (xtv), because he was going to do Major Changes
Real Soon Now.

I have an interest in keeping this ebuild in the tree, and would offer
my assistance to whatever effort Danny is engaged in.

Danny: Please put the ebuilds somewhere I can work on them, so that we
can get this baby working RSN;)

-- Karl T
--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Karl :-)

>>In case there are no security Bugs, i'd like to ask you to leave them in
>>for the time being, I'm working on getting the latest versions (8.0/8.1)
>>of ifort (how it is now known) and icc into the tree. The only problem
>>are my time constraints atm :-/. Though I have ebuilds ready, it will
>>still take some time to remove some minor itches before I'd commit them.

> Last time I started hacking on this, I was told to stop by the current
> maintainer at the time (xtv), because he was going to do Major Changes
> Real Soon Now.
>
> I have an interest in keeping this ebuild in the tree, and would offer
> my assistance to whatever effort Danny is engaged in.
>
> Danny: Please put the ebuilds somewhere I can work on them, so that we
> can get this baby working RSN;)

Please have a look at

http://dev.gentoo.org/~kugelfang/ebuilds/

where you should find ebuilds for icc, ifc and mkl. The icc one does
not yet fully work on amd64. ifc works fine and mkl too.

icc needs the most work still.

Danny
- --
Danny van Dyk <kugelfang@gentoo.org>
Gentoo/AMD64 Project, Gentoo Scientific Project
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCgo/WaVNL8NrtU6IRArtyAKCMv97hhKucFEkkXFTHiawlCyXeLQCeOjHM
/KzPTmS3/+/N2+8XBJ/88gE=
=vlp/
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Danny van Dyk wrote:
|>>Danny: Please put the ebuilds somewhere I can work on them, so that we
|>>can get this baby working RSN;)
|
|
| Please have a look at
|
| http://dev.gentoo.org/~kugelfang/ebuilds/
|
| where you should find ebuilds for icc, ifc and mkl. The icc one does
| not yet fully work on amd64. ifc works fine and mkl too.
|
| icc needs the most work still.

Do we have a bug concerning these ebuilds?
Should I dump all my comments on this mailing list?
Where else can we discuss this topic?

Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFCiH70QTaBhxBS2xERAqwpAJ9S9qYC6bmmAFNqn6jEOP/KmJE55gCcDRmI
Emoc2tKw6rw71r8a3/UoOIk=
=lPKp
-----END PGP SIGNATURE-----
--
gentoo-dev@gentoo.org mailing list