Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Different compilers and library
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
big_gie
Apprentice
Apprentice


Joined: 31 Aug 2004
Posts: 158

PostPosted: Tue Oct 24, 2006 7:21 pm    Post subject: Different compilers and library Reply with quote

Hi,

I'm using different set of compilers (gfortran, intel, pgi) and I would like to build libraries for all of them to use with my code.

Right now, I can't (or just don't see how) build multiple version of the library. I need to :
CC="gcc" CXX="g++" F77="gfortran" FC="gfortran" emerge -av sys-cluster/openmpi
to build using gnu, or :
CC="icc" CXX=$CC F77="ifc" FC="$F77" emerge -av sys-cluster/openmpi
to build with intel, etc. But after this I will get only one version, depending on the compiler used.

Is there a way to slot a single version of a package builded with different compiler? What I would like is having a version of that library (openmpi) for each compiler possible (gnu, intel and pgi) into different path like
/usr/lib/openmpi/gnu
/usr/lib/openmpi/intel
/usr/lib/openmpi/pgi

So I could compile my program with one of those compiler and link to the appropriate library....

Thanx
Back to top
View user's profile Send private message
Mad Merlin
Veteran
Veteran


Joined: 09 May 2005
Posts: 1143

PostPosted: Tue Oct 24, 2006 10:40 pm    Post subject: Reply with quote

AFAIK, there's no easy way to just slot an arbitrary package. Probably the easiest way to do what you want would be to emerge the package once with each compiler and then copy the libraries to ~/lib/ or /usr/local/lib/. It would be relatively easy to script the entire process if you're intending to maintain the setup (ie, it's not just some quick benchmarking or something similar) through newer package versions.
_________________
Game! - Where the stick is mightier than the sword!
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5236
Location: France, Old Europe

PostPosted: Wed Oct 25, 2006 7:13 am    Post subject: Reply with quote

It seems like you want to build the same package twice (using the different compilers) so you will need to separate the two installations. You could do this by the build prefix , eg install the intel based one in /opt/intel as is done with the compilers.

you would then probably need a short wrapper script to change the paths according to which one you want to run.

A quick and easy way if you have enough disk and dont have your entire system on one partition would be to clone your root partition and install the intel build in one and the gnu in the other then use chroot to when you want to use intel.

HTH 8)
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.

AthlonXP-M on A7N8X @ 2.6/2.4GHz (winter/summer)
2.6.32-hh1 : portage ~x86
Back to top
View user's profile Send private message
big_gie
Apprentice
Apprentice


Joined: 31 Aug 2004
Posts: 158

PostPosted: Fri Mar 16, 2007 11:19 pm    Post subject: Reply with quote

Hi,

Sorry Gentree I didn't saw your post!!! I'm posting what I've did.

I normally use the PGI compilers for fortran simulation. I also compile with ifort and gfortran to make sure my code is ok. So I need to compile my libraries with every compilers to be able to use them. One of those libaries is OpenMPI, another one is netCDF4. So I ended up with:
/usr/lib/netcdf/4.0-pgi
/usr/lib/netcdf/4.0-intel
/usr/lib/netcdf/4.0-gcc
When I compile using pgi, I link to the right path manually using -L. I want to access my data using python and its interface to netCDF4. So I must have a netcdf4 version compiled with gcc to use it with python, and one compiled with pgi for my simulation... Anyway you see the problem. For scientific programs, I need libraries built with optimizing compiler, and the rest can be compiled with gcc.

The only way I got this working was to :
1) Compile manually.
I don't like this since you loose the power of portage (upgrade, clean, etc.) and you can't use dependencies in ebuilds (netcdf4 (may) depends on hdf5, etc.)
2) Modify ebuils to point installation to /usr/lib/${PN}/${PV}-<compiler>
I've done this for netcdf4, hdf5 and openmpi. So I need to explicitly specify the path for linking.

Does anyone ever got the same issue? Is it something that can be suggested to devs? I understand it's not the intended way of doing things, but I think scientific applications require this.

What do you think?

Thanx
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5236
Location: France, Old Europe

PostPosted: Sat Mar 17, 2007 1:12 am    Post subject: Reply with quote

here's a wrapper that I use since I have gimp-2.2 and gimp-2.3.x installed concurrently.

gimp command runs that std package in std location , the following runs the latter with is gimp/lib elsewhere. This would seem similar to what I understand you are trying to do.

Code:
#!/bin/sh

PATH=/opt/gimp/bin:$PATH
export PATH
LD_LIBRARY_PATH=/opt/gimp/lib
export LD_LIBRARY_PATH

/opt/gimp/bin/gimp-2.3 "$@"


would you be better using the following to group all of your libs built on a given compiler together?
Code:
/usr/lib/${PV}-<compiler>


That way setting LD_LIBRARY_PATH to one location would allow you to switch between library builds.

You could add use options so that you only need to maintain one ebuild for each package and then install each version using portage:

USE="gfortran" emerge netcdf
USE="ifort" emerge netcdf
USE="pgi" emerge netcdf

I hope I've understood what you are aiming for.
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.

AthlonXP-M on A7N8X @ 2.6/2.4GHz (winter/summer)
2.6.32-hh1 : portage ~x86
Back to top
View user's profile Send private message
big_gie
Apprentice
Apprentice


Joined: 31 Aug 2004
Posts: 158

PostPosted: Sat Mar 17, 2007 2:09 am    Post subject: Reply with quote

Gentree wrote:
would you be better using the following to group all of your libs built on a given compiler together?
Code:
/usr/lib/${PV}-<compiler>


That way setting LD_LIBRARY_PATH to one location would allow you to switch between library builds.

Did you meant /usr/lib/<compiler>? ;) Yeah that could an interesting way. I began with one package, but for more it could be simpler. As for LD_LIBRARY_PATH, I saw everywhere that it should be avoided... So in my ebuilds I added "-Wl,-R<path>" to the cflags. That way, bins are compiled with absolute path to shared lib used:
Quote:
> ldd /usr/lib/netcdf/4.0-pgi/bin/ncdump
linux-gate.so.1 => (0xffffe000)
libnetcdf.so.5 => /usr/lib/netcdf/4.0-pgi/lib/libnetcdf.so.5 (0xb7ec9000)
libhdf5_hl.so.0 => /usr/lib/hdf5/1.8.0-alpha5-pgi/lib/libhdf5_hl.so.0 (0xb7e98000)
libhdf5.so.1 => /usr/lib/hdf5/1.8.0-alpha5-pgi/lib/libhdf5.so.1 (0xb7b06000)
libz.so.1 => /lib/libz.so.1 (0xb7ac8000)
libm.so.6 => /lib/libm.so.6 (0xb7aa4000)
libc.so.6 => /lib/libc.so.6 (0xb7983000)
libpgc.so => /opt/pgi_workstation/linux86/6.1/lib/libpgc.so (0xb7966000)
/lib/ld-linux.so.2 (0xb7f29000)

So I don't have to use LD_LIBRARY_PATH when I want to run /usr/lib/netcdf/4.0-pgi/bin/ncdump or /usr/lib/netcdf/4.0-gcc/bin/ncdump, they look for their right lib at the right place!

Gentree wrote:
You could add use options so that you only need to maintain one ebuild for each package and then install each version using portage:

USE="gfortran" emerge netcdf
USE="ifort" emerge netcdf
USE="pgi" emerge netcdf

I hope I've understood what you are aiming for.

This is the first way I went. I posted something on bugzilla (sorry I can't find it anymore! :?: ) some time ago. I adapted an ebuild for those useflag, but someone responded that it shouldn't be that way... He said I should use :
CC="pgcc" CXX="pgCC" F77="pgf77" FC="pgf90" emerge -av =sci-libs/hdf5-1.8.0_alpha5-r2
instead... So I adapted my ebuilds so they can detect wich compilers, then set the flags acordingly. But I think it would be more correct to have use flags, as you suggested.

This doesn't change the problem of the single package. Only the last one emerged will stay... The only workaround I found was using slots:
emerge -av =sci-libs/hdf5-1.8.0_alpha5-r1 (slot 1 with gcc)
CC="pgcc" CXX="pgCC" F77="pgf77" FC="pgf90" emerge -av =sci-libs/hdf5-1.8.0_alpha5-r2 (slot 2)
CC="icc" CXX="icc" F77="ifort" FC="ifort" emerge -av =sci-libs/hdf5-1.8.0_alpha5-r3 (slot 3)
(and so on)
with ebuilds installing in something like /usr/lib/hdf5-pgi (or any better combination of compilers/version/other...)

All this points to a portage issue (I think): support for different compilers is not good. I think their is some gcc profiles, but thats it. Nothing adapted for scientific libs. I could modify fortran.eclass for better support of different compilers, but the problem persist of cohabitation of multiple instance of the same program/libs. Setting slots work for different package version, but is not really adapted for a single version a package compiled with different compilers.

I think of two workarounds:
-Slots (or use flags) as shown above
-creating ebuilds specific to compilers: sci-libs/hdf5-pgi-1.8.0_alpha5, sci-libs/hdf5-gcc-1.8.0_alpha5 ...

Both are just workaround. For example, its a mess when new versions comes out! I'd like a more robust way. But that means portage hacking, doesn't it? Whats you though on this?
Back to top
View user's profile Send private message
big_gie
Apprentice
Apprentice


Joined: 31 Aug 2004
Posts: 158

PostPosted: Mon Mar 19, 2007 2:19 pm    Post subject: Reply with quote

I've got an idea last nigh ( :!: )

What about multiple use flags:
use="pgi intel gcc" emerge netcdf
which would compile a version for each of the compilers stated:
/usr/lib/gcc/netcdf/4.0 (or /usr/lib/netcdf/4.0)
/usr/lib/pgi/netcdf/4.0
/usr/lib/intel/netcdf/4.0

So:
-"emerge netcdf" would give:
/usr/lib/gcc/netcdf/4.0
-"use=pgi emerge netcdf" would give:
/usr/lib/gcc/netcdf/4.0
/usr/lib/pgi/netcdf/4.0

etc.

What do you think?
Back to top
View user's profile Send private message
big_gie
Apprentice
Apprentice


Joined: 31 Aug 2004
Posts: 158

PostPosted: Wed Mar 21, 2007 9:57 pm    Post subject: Reply with quote

Here's what I did:

I've made a generic ebuild for the library, with (almost) nothing in it. That ebuild depends on 3 other ebuilds conditionnally to use flags (gcc, pgi and intel). Those 3 ebuilds install the library with the correct compilers:
sci-libs/hdf5/hdf5-1.8.0_alpha5.ebuild
sci-libs/hdf5-gcc/hdf5-gcc-1.8.0_alpha5-r4.ebuild
sci-libs/hdf5-pgi/hdf5-pgi-1.8.0_alpha5-r4.ebuild
sci-libs/hdf5-intel/hdf5-intel-1.8.0_alpha5-r4.ebuild

The last 3 install their files in :
/usr/lib/gcc/hdf5/1.8.0-alpha5
/usr/lib/pgi/hdf5/1.8.0-alpha5
/usr/lib/intel/hdf5/1.8.0-alpha5

I've used that logic for netcdf4 also, which can depends on those:
sci-libs/netcdf/netcdf-4.0_alpha2007030802.ebuild
sci-libs/netcdf-gcc/netcdf-gcc-4.0_alpha2007030802.ebuild (files in /usr/lib/gcc/netcdf/4.0-alpha2007030802/)
sci-libs/netcdf-pgi/netcdf-pgi-4.0_alpha2007030802.ebuild (files in /usr/lib/pgi/netcdf/4.0-alpha2007030802/)
sci-libs/netcdf-intel/netcdf-intel-4.0_alpha2007030802.ebuild (files in /usr/lib/intel/netcdf/4.0-alpha2007030802/)

And finally a python module for netcdf4 reading, which depends on sci-libs/netcdf-gcc :
sci-libs/python-netcdf4/python-netcdf4-0.6.2-r1.ebuild

This help for scientific libraries for use by programs compiled with different compilers. I want to link to hdf5 and netcdf4 from my fortran code which can be built with gcc, pgi or intel and this is the "cleaner" solution I've found...

Any comments? Should that go directly to bugzilla?
Back to top
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 9013
Location: beyond the rim

PostPosted: Thu Mar 22, 2007 5:46 am    Post subject: Reply with quote

The easiest work around would probably be to set up 3 different chroot environments (using $ROOT and $PORTAGE_CONFIGROOT), one for each compiler/toolchain, just requires a bit more CPU time and diskspace to install and update all three systems. Has also the benefit that you can eventually use different versions of a library for each compiler if that need should ever arise.

For a real solution you basically want a new variable similar to SLOT that's dynamically generated by some env variable (like CC). There are several issues right now that prevent such a thing, mainly the lack of SLOT deps (well, they exist but can't be used yet, and would probably have to be changed for this first) and the "metadata-constant" cache restriction that requires that dependency resolution can't use system specific information (like environment variables) but only constant data as it has to be serialized.
Your proposal of making multiple packages for each compiler has the nasty problem that it doesn't scale very well and requires pointless duplication of code and data. The solution with USE flags is a bit better but would need USE dependencies first to really work.
Back to top
View user's profile Send private message
hanni_ali
n00b
n00b


Joined: 16 Jun 2005
Posts: 57
Location: UK, London

PostPosted: Thu Mar 22, 2007 4:19 pm    Post subject: Reply with quote

How about using an eselect class to define which environment you want to use such that a symlink points to the desired library hence removing the reliance on using -L.

So by installing all the different versions compiled with the different compilers it would be possible to dynamically switch between them. This in combination with the use flags would cover the majority of the issues. Does anyone agree?

Hanni
Back to top
View user's profile Send private message
big_gie
Apprentice
Apprentice


Joined: 31 Aug 2004
Posts: 158

PostPosted: Thu Mar 22, 2007 5:13 pm    Post subject: Reply with quote

Genone wrote:
The easiest work around would probably be to set up 3 different chroot environments (using $ROOT and $PORTAGE_CONFIGROOT), one for each compiler/toolchain, just requires a bit more CPU time and diskspace to install and update all three systems. Has also the benefit that you can eventually use different versions of a library for each compiler if that need should ever arise.

I don't know if I'm following you... :roll: What I did allows me to install multiple versions too...

Genone wrote:
For a real solution you basically want a new variable similar to SLOT that's dynamically generated by some env variable (like CC). There are several issues right now that prevent such a thing, mainly the lack of SLOT deps (well, they exist but can't be used yet, and would probably have to be changed for this first) and the "metadata-constant" cache restriction that requires that dependency resolution can't use system specific information (like environment variables) but only constant data as it has to be serialized.

I still don't follow you... :?

Genone wrote:
Your proposal of making multiple packages for each compiler has the nasty problem that it doesn't scale very well and requires pointless duplication of code and data.

Yeah I know... This is why I was a bit skeptical and wanted others opinion... It is true that for one lib, there is 4 ebuilds (and could be more...) which is not the best. But since the same library can't be built the same way for each compilers, it is not possible to have just one global ebuild. I did this first, but the ebuild get really complicated, proned to bugs, and the upgrade is a pain. You absolutely need the re-emerge the lib the same way you did first, with like "CC=pgcc CXX=pgCC FC=pgf90 F77=pgf77 emerge -v =sci-libs/$PN-$PV" and the same for all the others. Having separate ebuilds let the possibility to "emerge --update --deep --ask --verbose --newuse world" correctly.

Genone wrote:
The solution with USE flags is a bit better but would need USE dependencies first to really work.

Here is the dep part of the ebuilds:
sci-libs/hdf5/hdf5-1.8.0_alpha5-r4.ebuild:
Code:
[...]
IUSE="gcc intel pgi"
DEPEND="
        gcc? ( =sci-libs/${PF/hdf5-/hdf5-gcc-} )
        pgi? ( =sci-libs/${PF/hdf5-/hdf5-pgi-} )
        intel? ( =sci-libs/${PF/hdf5-/hdf5-intel-} )"
[...]

sci-libs/hdf5-gcc/hdf5-gcc-1.8.0_alpha5-r4.ebuild:
Code:
[...]
IUSE="ssl szip zlib static debug threads cxx fortran hlapi mpi lfs"
DEPEND="
        [...]
        fortran? ( >=sys-devel/gcc-4.1 )"
[...]

sci-libs/hdf5-pgi/hdf5-pgi-1.8.0_alpha5-r4.ebuild:
Code:
[...]
IUSE="ssl szip zlib static debug threads cxx fortran hlapi mpi lfs"
DEPEND="
        [...]
        dev-lang/pgi-workstation"
[...]

sci-libs/hdf5-intel/hdf5-intel-1.8.0_alpha5-r4.ebuild:
Code:
[...]
IUSE="ssl szip zlib static debug threads cxx fortran hlapi mpi lfs"
DEPEND="
        [...]
        dev-lang/icc
        fortran? ( dev-lang/ifc ) "
[...]

Is this what you meant?


hanni_ali wrote:
How about using an eselect class to define which environment you want to use such that a symlink points to the desired library hence removing the reliance on using -L.

So by installing all the different versions compiled with the different compilers it would be possible to dynamically switch between them. This in combination with the use flags would cover the majority of the issues. Does anyone agree?

That could be a plus and would be interesting to see included, but does not correct the problem of installing multiple instances of a single library, compiled with different compilers (where do you install them? how does portage manage them?)
Back to top
View user's profile Send private message
Genone
Retired Dev
Retired Dev


Joined: 14 Mar 2003
Posts: 9013
Location: beyond the rim

PostPosted: Fri Mar 23, 2007 3:57 am    Post subject: Reply with quote

big_gie wrote:
Genone wrote:
The easiest work around would probably be to set up 3 different chroot environments (using $ROOT and $PORTAGE_CONFIGROOT), one for each compiler/toolchain, just requires a bit more CPU time and diskspace to install and update all three systems. Has also the benefit that you can eventually use different versions of a library for each compiler if that need should ever arise.

I don't know if I'm following you... :roll: What I did allows me to install multiple versions too...

But requires you to manually maintain those ebuilds, right? My suggestion would just use the normal ebuilds (assuming they don't need any other changes), so you wouldn't have to worry about version bumps and stuff like that.

Quote:
Genone wrote:
For a real solution you basically want a new variable similar to SLOT that's dynamically generated by some env variable (like CC). There are several issues right now that prevent such a thing, mainly the lack of SLOT deps (well, they exist but can't be used yet, and would probably have to be changed for this first) and the "metadata-constant" cache restriction that requires that dependency resolution can't use system specific information (like environment variables) but only constant data as it has to be serialized.

I still don't follow you... :?

What I wanted to say is that it's not exactly a new problem, but the ideal solution isn't possible yet due to restrictions within portage (and no, I don't think that paludis or pkgcore can handle that yet either). Sorry if the details confused you :wink:

Quote:
Genone wrote:
Your proposal of making multiple packages for each compiler has the nasty problem that it doesn't scale very well and requires pointless duplication of code and data.

Yeah I know... This is why I was a bit skeptical and wanted others opinion... It is true that for one lib, there is 4 ebuilds (and could be more...) which is not the best. But since the same library can't be built the same way for each compilers, it is not possible to have just one global ebuild. I did this first, but the ebuild get really complicated, proned to bugs, and the upgrade is a pain. You absolutely need the re-emerge the lib the same way you did first, with like "CC=pgcc CXX=pgCC FC=pgf90 F77=pgf77 emerge -v =sci-libs/$PN-$PV" and the same for all the others. Having separate ebuilds let the possibility to "emerge --update --deep --ask --verbose --newuse world" correctly.

Yeah, currently that's not really feasable unfortunately, hopefully that will change in the future.

Quote:
Genone wrote:
The solution with USE flags is a bit better but would need USE dependencies first to really work.

Here is the dep part of the ebuilds:
sci-libs/hdf5/hdf5-1.8.0_alpha5-r4.ebuild:
Code:
[...]
IUSE="gcc intel pgi"
DEPEND="
        gcc? ( =sci-libs/${PF/hdf5-/hdf5-gcc-} )
        pgi? ( =sci-libs/${PF/hdf5-/hdf5-pgi-} )
        intel? ( =sci-libs/${PF/hdf5-/hdf5-intel-} )"
[...]

Is this what you meant?

Nope. I don't know the library in question so it may not be an issue in that particular case, but in general there will be problems when something depends on a library being compiled with the same compiler (e.g. A depends on B compiled with compiler C), that can't be expressed with the current dependency syntax.
Back to top
View user's profile Send private message
hanni_ali
n00b
n00b


Joined: 16 Jun 2005
Posts: 57
Location: UK, London

PostPosted: Fri Mar 23, 2007 9:34 am    Post subject: Reply with quote

Although using the chroots with multiple versions of compiled systems would provide a solution it would infact be less "simple" than you think. First if running MPI you would need to set-up the chroots on all the machines in your cluster and if running a heterogeneous cluster you would need to test the chroot across all the machines and maintaining the cluster could become a nightmare.

Then comes the issues when installing different versions of MPI http://bugs.gentoo.org/show_bug.cgi?id=44132 (I note big_gie has raised the issue in discussion here, there, as well) on the same system you would require even more chroot environments and in particular my preference for cluster/network operating systems is to minimise network traffic and if on selecting a different chroot and set that up before they can begin processing (all our clusters run diskless) this put's unecessary load on the network.

The point is there must be a more elegant and most importantly more maintainable method for managing different MPI implementations and compilers and their respective versions!

In my opinion a combination of some form of config selection (eselct or mpi-config), with appropriate use flags, virtual ebuilds which pull in the necessary stuff and may even run some sanity tests and perhaps some patches for ./configs of applications dependent on mpi systems to check that the currently selected mpi environment contains the necessary functionality, or alternatively if the application depends on a specific version only, then perhaps hard coding the path would be most sensible.

Keep the ideas coming.

Hanni

P.S. did you read this http://bugs.gentoo.org/show_bug.cgi?id=30453#c22 the ideas discussed there if considered could help in particular:

Quote:
What about use of this info?
I think that running automatically blas-config from pkg_setup is a bad idea.
First, messing with system environment is not gonna be wellcomed by admins and,
second, this seems to be a bit against the Gentoo "approach". Instead ebuilds
should perhaps simply check what blas implementation was used, check which one
is active and then either carry on or stop with informative message. For
immediate blas dependants this can be just a warning and some env var can be
accepted to force rebuilding against presently active blas (although the same
effect can be had by simply unmerging and then emerging the package, but
accepting env var seems to be "cleaner"). For the distantiated dependants (e.g.
that include lapack as well) is should be the genuine stop with message asking
to either activate appropriate blas or to remerge lapack against presently
active one (or activate corresponding lapack).
[/quote]
Back to top
View user's profile Send private message
big_gie
Apprentice
Apprentice


Joined: 31 Aug 2004
Posts: 158

PostPosted: Mon Mar 26, 2007 1:41 pm    Post subject: Reply with quote

Genone wrote:
I don't know the library in question so it may not be an issue in that particular case, but in general there will be problems when something depends on a library being compiled with the same compiler (e.g. A depends on B compiled with compiler C), that can't be expressed with the current dependency syntax.

Following what I did, packages that must depend on that library must depend on "sci-libs/hdf5-gcc" or "sci-libs/hdf5-pgi" or "sci-libs/hdf5-intel" depending on the required compiler. I see a problem if someone want just one instance of the library compiled with gcc. He should use the "gcc" use flag of "sci-libs/hdf5". It could be possible to make the "sci-libs/hdf5" ebuild equivalent to "sci-libs/hdf5-gcc". That way, the gcc version would always be compiled. But users could choose to install "sci-libs/hdf5-pgi" and "sci-libs/hdf5-intel" with USE="pgi intel" emerge -av "sci-libs/hdf5" That would simplify usage by normal users, while still gives the possibility for advanced users to have more than one instance.

I know having ebuilds for each compilers would add a bit of complexity. But it does simplify the main ebuild (there is no "if compiler == gcc [...] elseif compiler == pgi ...")

hanni_ali wrote:
The point is there must be a more elegant and most importantly more maintainable method for managing different MPI implementations and compilers and their respective versions!

There is two problems here:
  • Multiple MPI implementation installed (OpenMPI, MPICH, MPICH2, LAM-MPI, etc.)
  • A single package (one mpi implementation or another library like hdf5) but installed multiple times, compiled with different compilers

Those are not the same problems, but are similar. Resolving one may help the other. The first one could be corrected with:
  • ebuilds installing files in their own folders (ie /urs/lib/openmpi, /urs/lib/mpich, /urs/lib/mpich2, etc.).
  • ebuilds should not block others
  • ebuilds should provide virtual/mpi and a way to switch easily from one to another, like eselect


hanni_ali wrote:
P.S. did you read this http://bugs.gentoo.org/show_bug.cgi?id=30453#c22 the ideas discussed there if considered could help in particular

For what I understand, that bugzilla entry says that the ebuild should let configure detect which library to use instead of sepcifiying one with blas-config. I don't think it is mendatory to call something like blas-config inside the ebuild. It could be called before emerge by the user. I don't think this would block our ideas.

Thanx for your post and ideas!
Back to top
View user's profile Send private message
hanni_ali
n00b
n00b


Joined: 16 Jun 2005
Posts: 57
Location: UK, London

PostPosted: Mon Mar 26, 2007 1:52 pm    Post subject: Reply with quote

Have you put the ebuilds you are working on anywhere? I'd be interested in seeing them and I think your suggestion is an excellent way to deal with this.

A virtual for all libs which could be built with different compilers which uses a use flag during the build to select the compiler and an eselect class to select the lib at runtime.

Where the default configuration would install the standard gcc versions.
Back to top
View user's profile Send private message
big_gie
Apprentice
Apprentice


Joined: 31 Aug 2004
Posts: 158

PostPosted: Tue Mar 27, 2007 3:21 pm    Post subject: Reply with quote

hanni_ali wrote:
Have you put the ebuilds you are working on anywhere? I'd be interested in seeing them and I think your suggestion is an excellent way to deal with this.

I didn't posted them earlier because since I first write them for myself, theyr are not necessarily optimized for others. I wanted to have feedback first.

You will find my local overlay there:
http://nbigaouette.inrs-emt.homelinux.net/linux/gentoo/overlay/

What you will want to look at is sci-libs/hdf5:
http://nbigaouette.inrs-emt.homelinux.net/linux/gentoo/overlay/sci-libs/hdf5/
http://nbigaouette.inrs-emt.homelinux.net/linux/gentoo/overlay/sci-libs/hdf5-pgi/
http://nbigaouette.inrs-emt.homelinux.net/linux/gentoo/overlay/sci-libs/hdf5-intel/

Those ebuilds are the most up to date. I didn't have time to work on sci-libs/netcdf or sys-cluster/openmpi to reflect the latest propositions. (I also have trouble compiling openmpi with intel's icc/icpc v9.1)
Back to top
View user's profile Send private message
khpae
n00b
n00b


Joined: 11 Dec 2006
Posts: 4

PostPosted: Tue Oct 30, 2007 12:58 am    Post subject: Reply with quote

i'm using ~amd64 profile (multilib) on a em64t (C2Q) system.
i got problem on installing openmpi-intel package.
here's what i did :
installed icc / ifc 10.0.026.
downloaded your openmpi-intell-1.1.5 ebuild and changed it to openmpi-intel-1.2.4.
edited the content of the ebuild accordingly, of course.
created /usr/local/portage/sys-cluster/openmpi-intel directory and placed it there.
added these lines in the /etc/make.conf file.
Code:

PORTDIR_OVERLAY="/usr/local/portage"
PORTDIR_OVERLAY="${PORTDIR_OVERLAY} /usr/local/portage/sys-cluster"

and then, did digest and manifest for the ebuild by using ebuild command.
everything went fine upto this point.
but when i try emerge -Dv openmpi-intel, there came error in configuring phase.
Code:

...
 * Configure will be called with those options:
 *  --prefix=/usr/lib/intel/openmpi/1.2 --datadir=/usr/lib/intel/openmpi/1.2 --sysconfdir=/etc/openmpi/1.2-intel --mandir=/usr/lib/intel/openmpi/1.2/share/man --infodir=/usr/lib/intel/openmpi/1.2/share/info --enable-pretty-print-stacktrace --enable-static --without-memory-manager --enable-shared --enable-mpi-f77 --enable-mpi-f90 --enable-mpi-cxx CXX=icpc --with-wrapper-ldflags=-Wl,-R/usr/lib/intel/openmpi/1.2/lib CC=icc F77=ifort FC=ifort
...
*** C compiler and preprocessor
checking for style of include used by make... GNU
checking for gcc... icc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
...
 *  The die message:
 *   ./configure failed
...

it seems that my env is not set correctly, but on the command line, i can compile simple C programs by using icc. and it runs well.
any help will be appreciated.
Back to top
View user's profile Send private message
khpae
n00b
n00b


Joined: 11 Dec 2006
Posts: 4

PostPosted: Tue Oct 30, 2007 1:43 am    Post subject: Reply with quote

nevermind. i solved the problem. was my fault.
some CFLAGS were not filtered correctly.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum