Re: [Fink-devel] boost1.55.info thinko
Hanspeter, I've updated the openmpi packaging in the 10.7 tree to build the newer 1.8.1 openmpi release using the system c/c++ compilers for 10.7/10.8 as was already being done on 10.9. I've added the following change to the boost1.55.info packaging in the 10.7 tree to adjust for this change. Index: boost1.55.info === RCS file: /cvsroot/fink/dists/10.7/stable/main/finkinfo/libs/boost1.55.info ,v retrieving revision 1.2 diff -r1.2 boost1.55.info 4c4 Revision: 2 --- Revision: 3 13,14c13,14 gcc48-compiler, openmpi, --- gcc49-compiler, openmpi (= 1.8.1-3), 99,100c99,100 if [ `uname -r | cut -d. -f1` -lt 13 ]; then perl -pi -e 's|g\+\+|%p/bin/g++-fsf-4.8|g' tools/build/v2/tools/darwin.jam --- if [ `uname -r | cut -d. -f1` -lt 11 ]; then perl -pi -e 's|g\+\+|%p/bin/g++-fsf-4.9|g' tools/build/v2/tools/darwin.jam 207,208c207,208 gcc48-shlibs, openmpi-shlibs, --- gcc49-shlibs, openmpi-shlibs (= 1.8.1-3), This rationalizes the linkages on 10.7/10.8 to use the proper system libstdc++ library so that programs linking in boost1.55-shlibs don't have to worry about linking in multiple libstdc++ libraries and any incompatibilities that would cause. Jack ps I also took the opportunity to bump the openmpi package to use the latest gcc49-compiler package hence the same change in boost1.55.info. On Sat, Apr 26, 2014 at 7:43 PM, Hanspeter Niederstrasser f...@snaggledworks.com wrote: On Sat, April 26, 2014 11:14 am, Jack Howarth wrote: Hanspeter, What is the logic behind making boost1.55 build against the g++-fsf-4.8 compiler instead of clang++ on 10.9 and later? By doing that, you require any program that links against boost1.55 and all of its support libraries to be built with g++-fsf-4.8. We were very careful when Mavericks landed to make sure that boost1.53 properly built against libc++ from clang++ rather than any of the libstdc++ releases (system or fsf gcc). This seems like a major regression in the packaging compared to boost1.53. I am surprised you resorted to that as the newer boost release should have even more libc++ related fixes than 1.53 did. Jack Jack, I'm currently traveling and unable to test any issues until Wednesday at the earliest, but more likely not until the weekend. I'm OK with the 10.9 conditional you put in to build with clang++ on 10.9 (plus the atomic patch). I'll be back towards the middle/end of the week to further discuss as needed. If you feel more changes are needed, please discuss on here or on #fink with dmacks since he'll understand issues that may arise from the package management end. Thanks for your help, Hanspeter -- More agile than a turtle, stronger than a mouse, nobler than a lettuce -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] boost1.55.info thinko
Hanspeter, Just to clarify things, the history of openmpi is as follows. Originally when I picked up the package it was designed to use only the fortran compiler from the gcc4x-compiler packages and the system gcc and cc compilers were used for c and c++ code. I got a number of user requests to switch the c and c+ compilers to those in the gcc4x-compiler package as well. That change became much more problematic with the switch of the system c++ library from the libstdc++ ABI to the libc++ ABI in 10.9 hence the switch back to the system compilers for mpicc and mpicxx. While this lost us the option of simultaneously enabling openmp (which is different) in the code, that limitation should disappear in a future clang release once Apple has fully merged the donated Intel openmp code base into llvm. Jack ps In the past, I wan't that concerned about the use of the gcc4x-compiler c/c++ compilers in openmpi as code that used it tended to not have many or any c++ support libraries to worry about so that the compiles where pretty self contained. The boost situation is quite different. There are a lot of complex builds that use boost which would require swaths of the fink package set to be rebuilt against g++-fsf-4.8 for properly standardized linkage on the same libstdc++ throughout. Also, it is a corner case that users would really want to run their application with openmpi. Especially with boost which already approaches that problem via threading. Enabling openmpi support in boost doesn't make much sense for a single workstation and only becomes sensible if the user is running the program across a number of different workstations via openmpi so it only makes sense as a boost-openmpi variant. Considering that Apple may remove their ancient gas assembler, essential for the FSF gcc compilers to function, in some future Xcode release, we should attempt to avoid unnecessary usage of the gcc4x packages unless they are essential. This will limit the carnage that will ensue when Apple depreciates gas (as they still haven't made any commitment to providing a stand alone replacement based on the integrated assembler from clang). When Mavericks support in fink was being developed, I initially proposed adding a check for this mixing of incompatible c++ libraries but never pushed it as every case that I looked at failed to link due to the incompatible symbols in the libstdc++ and libc++. On Sat, Apr 26, 2014 at 1:13 PM, Jack Howarth howarth.at.f...@gmail.comwrote: Hanspeter, Okay, I see now that you are trying to leverage the openmpi support in boost. This creates two different problems. 1) On 10.8 and earlier, openmpi uses the gcc-fsf-4.8 and g++-fsf-4.8 compilers so you would need to compile boost against that compiler. However this will mean that when you link other c++ programs and c++ support libraries against boost1.55 on 10.8 or earlier, it will be mixing two different libstdc++ releases. The c++ program and support libraries will be linked against the system libstdc++ (which is from gcc 4.2.1) and boost1.55 will be linked against the newer libstdc++ from gcc48. This might work but isn't really a good idea in general. 2) On 10.9 and later, the openmpi compiler wrappers call the clang and clang++ compilers for c and c++ code and the gfortran-fsf-4.8 compiler for fortran code. So your packaging is broken on 10.9 in that it breaks the expected compiler usage for openmpi and prevents the c++ code from being generated to use libc++. The libc++ and libstdc++ ABIs are incompatible and never should be mixed. On 10.9, you at least want to create a 10.9 variant for boost1.55 which removes the usage of gcc-fsf-4.8 and g++-fsf-4.8 and restores the usage of the clang and clang++ compilers via the compiler wrappers. On reflection, I also don't think you want the stock boost1.55 to build against openmpi in any case. There should be a boost1.55-openmpi variant to do that. It really doesn't make sense to build the library as openmpi code unless you intend to force all the packages that use boost1.55 to be built with mpicc. mpicxx and mpif90. Jack ps Also are you sure you didn't enable openmpi in boost1.55 simply because you were confusing it with openmp? The openmp support is much more transparent and doesn't require the resulting executables to be executed through utility programs ala mdrun like openmpi. On Sat, Apr 26, 2014 at 12:14 PM, Jack Howarth howarth.at.f...@gmail.comwrote: Hanspeter, What is the logic behind making boost1.55 build against the g++-fsf-4.8 compiler instead of clang++ on 10.9 and later? By doing that, you require any program that links against boost1.55 and all of its support libraries to be built with g++-fsf-4.8. We were very careful when Mavericks landed to make sure that boost1.53 properly built against libc++ from clang++ rather than any of the libstdc++ releases (system or fsf gcc). This
Re: [Fink-devel] boost1.55.info thinko
Hanspeter, I would also point out that the reason that the boost1.xx releases prior to boost1.53 don't exist on 10.9 is that boost1.53 was the first release sufficiently patched for libc++ to properly build against the new default c++ library on 10.9. If you had problems building boost1.55 against the newer Xcode 5.1, there are patches back ported from upstream to fix that… https://trac.macports.org/browser/trunk/dports/devel/boost/files/patch-atomic.diff Jack On Sat, Apr 26, 2014 at 12:14 PM, Jack Howarth howarth.at.f...@gmail.comwrote: Hanspeter, What is the logic behind making boost1.55 build against the g++-fsf-4.8 compiler instead of clang++ on 10.9 and later? By doing that, you require any program that links against boost1.55 and all of its support libraries to be built with g++-fsf-4.8. We were very careful when Mavericks landed to make sure that boost1.53 properly built against libc++ from clang++ rather than any of the libstdc++ releases (system or fsf gcc). This seems like a major regression in the packaging compared to boost1.53. I am surprised you resorted to that as the newer boost release should have even more libc++ related fixes than 1.53 did. Jack -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] boost1.55.info thinko
Hanspeter, Okay, I see now that you are trying to leverage the openmpi support in boost. This creates two different problems. 1) On 10.8 and earlier, openmpi uses the gcc-fsf-4.8 and g++-fsf-4.8 compilers so you would need to compile boost against that compiler. However this will mean that when you link other c++ programs and c++ support libraries against boost1.55 on 10.8 or earlier, it will be mixing two different libstdc++ releases. The c++ program and support libraries will be linked against the system libstdc++ (which is from gcc 4.2.1) and boost1.55 will be linked against the newer libstdc++ from gcc48. This might work but isn't really a good idea in general. 2) On 10.9 and later, the openmpi compiler wrappers call the clang and clang++ compilers for c and c++ code and the gfortran-fsf-4.8 compiler for fortran code. So your packaging is broken on 10.9 in that it breaks the expected compiler usage for openmpi and prevents the c++ code from being generated to use libc++. The libc++ and libstdc++ ABIs are incompatible and never should be mixed. On 10.9, you at least want to create a 10.9 variant for boost1.55 which removes the usage of gcc-fsf-4.8 and g++-fsf-4.8 and restores the usage of the clang and clang++ compilers via the compiler wrappers. On reflection, I also don't think you want the stock boost1.55 to build against openmpi in any case. There should be a boost1.55-openmpi variant to do that. It really doesn't make sense to build the library as openmpi code unless you intend to force all the packages that use boost1.55 to be built with mpicc. mpicxx and mpif90. Jack ps Also are you sure you didn't enable openmpi in boost1.55 simply because you were confusing it with openmp? The openmp support is much more transparent and doesn't require the resulting executables to be executed through utility programs ala mdrun like openmpi. On Sat, Apr 26, 2014 at 12:14 PM, Jack Howarth howarth.at.f...@gmail.comwrote: Hanspeter, What is the logic behind making boost1.55 build against the g++-fsf-4.8 compiler instead of clang++ on 10.9 and later? By doing that, you require any program that links against boost1.55 and all of its support libraries to be built with g++-fsf-4.8. We were very careful when Mavericks landed to make sure that boost1.53 properly built against libc++ from clang++ rather than any of the libstdc++ releases (system or fsf gcc). This seems like a major regression in the packaging compared to boost1.53. I am surprised you resorted to that as the newer boost release should have even more libc++ related fixes than 1.53 did. Jack -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] boost1.55.info thinko
Hanspeter, What is the logic behind making boost1.55 build against the g++-fsf-4.8 compiler instead of clang++ on 10.9 and later? By doing that, you require any program that links against boost1.55 and all of its support libraries to be built with g++-fsf-4.8. We were very careful when Mavericks landed to make sure that boost1.53 properly built against libc++ from clang++ rather than any of the libstdc++ releases (system or fsf gcc). This seems like a major regression in the packaging compared to boost1.53. I am surprised you resorted to that as the newer boost release should have even more libc++ related fixes than 1.53 did. Jack -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] boost1.55.info thinko
Hanspeter,
I committed the following changes to boost1.55.info in 10.7 tree
which rationalizes the packaging on 10.9 so that it
builds against the correct libc++ c++ library (which is the same one that
openmpi on 10.9 or later uses)…
Index: boost1.55.info
===
RCS file: /cvsroot/fink/dists/10.7/stable/main/finkinfo/libs/boost1.55.info
,v
retrieving revision 1.1
diff -r1.1 boost1.55.info
4c4
Revision: 1
---
Revision: 2
82c82,84
---
### Upstream fix for clang 3.4
https://github.com/boostorg/atomic/commit/6bb71fdd8f7cc346d90fb14beb38b7297fc1ffd9
PatchFile3: boost1.55-atomic.patch
PatchFile3-MD5: 9dccb1387d5d59bc1b392a1686fd827a
94a97
patch -p0 %{PatchFile3}
96c99,101
perl -pi -e 's|g\+\+|%p/bin/g++-fsf-4.8|g'
tools/build/v2/tools/darwin.jam
---
if [ `uname -r | cut -d. -f1` -lt 13 ]; then
perl -pi -e 's|g\+\+|%p/bin/g++-fsf-4.8|g'
tools/build/v2/tools/darwin.jam
fi
The new revision uses the same atomics patch as MacPorts to fix a
compilation error with clang 3.4 or later. This is a back port
of the upstream fix from
https://github.com/boostorg/atomic/commit/6bb71fdd8f7cc346d90fb14beb38b7297fc1ffd9and
should be
in the next boost minor release.
I am still concerned about how we are building boost1.55 on 10.8 and
earlier. As packages switch from boost1.53 to boost1.55,
the resulting builds should be tested with a test suite or manual run to
insure that this mixing of the FSF libstdc++ from gcc48
and the much older system libstdc++ doesn't cause weird run time issues.
This is one reason I was happy to switch openmpi
on 10.9 to use clang/clang++. If this mixing of the two different libstdc++
releases does in fact destabilize the resulting code,
I am open to upgrading and revamping the openmpi in 10.8 and earlier so
that it is on the current upstream release (1.8.1) and
builds with the system c/c++ compilers (i.e. uses the system libstdc++).
Jack
ps While the gcc48-compiler dependency in the info file appears at first
unnecessary for 10.9, it is actually a non-issue since the
openmpi dependency drags that in anyway on 10.9.
pps I suspect we ought to revision bump any packages which have been
recently converted from boost1.53 to boost1.55 to
insure that the files are relinked against the new shared libs that use the
correct libc++ ABI on 10.9.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] boost1.55.info thinko
Hanspeter,
It appears that the boost.mpi support can be tested (according to
http://www.boost.org/doc/libs/1_55_0/doc/html/mpi/getting_started.html)
as follows. On a build with 'fink -m -kK', execute…
cd /sw/src/fink.build/boost1.55-nopython-1.55.0-2/boost_1_55_0/libs/mpi/test
/sw/src/fink.build/boost1.55-nopython-1.55.0-2/boost_1_55_0/bjam
which produces…
...failed updating 1 target...
...skipped 307 targets...
...updated 458 targets...
at the end of the test suite run on darwin13 with a build of the new
boost1.55-nopython-1.55.0-2 packaging.
The documentation says that if no errors are reported it passed.
Jack
On Sat, Apr 26, 2014 at 6:21 PM, Jack Howarth howarth.at.f...@gmail.comwrote:
Hanspeter,
I committed the following changes to boost1.55.info in 10.7 tree
which rationalizes the packaging on 10.9 so that it
builds against the correct libc++ c++ library (which is the same one that
openmpi on 10.9 or later uses)…
Index: boost1.55.info
===
RCS file: /cvsroot/fink/dists/10.7/stable/main/finkinfo/libs/
boost1.55.info,v
retrieving revision 1.1
diff -r1.1 boost1.55.info
4c4
Revision: 1
---
Revision: 2
82c82,84
---
### Upstream fix for clang 3.4
https://github.com/boostorg/atomic/commit/6bb71fdd8f7cc346d90fb14beb38b7297fc1ffd9
PatchFile3: boost1.55-atomic.patch
PatchFile3-MD5: 9dccb1387d5d59bc1b392a1686fd827a
94a97
patch -p0 %{PatchFile3}
96c99,101
perl -pi -e 's|g\+\+|%p/bin/g++-fsf-4.8|g'
tools/build/v2/tools/darwin.jam
---
if [ `uname -r | cut -d. -f1` -lt 13 ]; then
perl -pi -e 's|g\+\+|%p/bin/g++-fsf-4.8|g'
tools/build/v2/tools/darwin.jam
fi
The new revision uses the same atomics patch as MacPorts to fix a
compilation error with clang 3.4 or later. This is a back port
of the upstream fix from
https://github.com/boostorg/atomic/commit/6bb71fdd8f7cc346d90fb14beb38b7297fc1ffd9and
should be
in the next boost minor release.
I am still concerned about how we are building boost1.55 on 10.8 and
earlier. As packages switch from boost1.53 to boost1.55,
the resulting builds should be tested with a test suite or manual run to
insure that this mixing of the FSF libstdc++ from gcc48
and the much older system libstdc++ doesn't cause weird run time issues.
This is one reason I was happy to switch openmpi
on 10.9 to use clang/clang++. If this mixing of the two different
libstdc++ releases does in fact destabilize the resulting code,
I am open to upgrading and revamping the openmpi in 10.8 and earlier so
that it is on the current upstream release (1.8.1) and
builds with the system c/c++ compilers (i.e. uses the system libstdc++).
Jack
ps While the gcc48-compiler dependency in the info file appears at first
unnecessary for 10.9, it is actually a non-issue since the
openmpi dependency drags that in anyway on 10.9.
pps I suspect we ought to revision bump any packages which have been
recently converted from boost1.53 to boost1.55 to
insure that the files are relinked against the new shared libs that use
the correct libc++ ABI on 10.9.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] boost1.55.info thinko
On Sat, April 26, 2014 11:14 am, Jack Howarth wrote: Hanspeter, What is the logic behind making boost1.55 build against the g++-fsf-4.8 compiler instead of clang++ on 10.9 and later? By doing that, you require any program that links against boost1.55 and all of its support libraries to be built with g++-fsf-4.8. We were very careful when Mavericks landed to make sure that boost1.53 properly built against libc++ from clang++ rather than any of the libstdc++ releases (system or fsf gcc). This seems like a major regression in the packaging compared to boost1.53. I am surprised you resorted to that as the newer boost release should have even more libc++ related fixes than 1.53 did. Jack Jack, I'm currently traveling and unable to test any issues until Wednesday at the earliest, but more likely not until the weekend. I'm OK with the 10.9 conditional you put in to build with clang++ on 10.9 (plus the atomic patch). I'll be back towards the middle/end of the week to further discuss as needed. If you feel more changes are needed, please discuss on here or on #fink with dmacks since he'll understand issues that may arise from the package management end. Thanks for your help, Hanspeter -- More agile than a turtle, stronger than a mouse, nobler than a lettuce -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] boost1.55.info thinko
Hanspeter, No problem. On 10.8 and earlier, there isn't a completely painless option. Mixing the two different libstdc++'s by linkage into the same program can be a tricky proposition, but reverting openmpi to build against the system libstdc++ will also break existing binaries. However, since I had been putting off upgrading the openmpi in 10.8 and earlier (as the ABI was broken between the 1.6.x and 1.7.x releases), we could accept that pain for the benefit of getting current with the openmpi code base in 10.8 and earlier. Also, packages that use openmpi are a special case anyway as we periodically switch the gcc4x used by the openmpi package to a later release. I've leaned against creating -gcc4x variants for the openmpi package in order to drive us to the latest gcc4x release and limit the number of different gcc4x packages that have to be installed on any one machine. Macports takes the opposite approach and creates a truly insane number of openmpi package variants. The main reason folks wanted to use the gcc4x compilers for mpicc and mpicxx was to obtain openmp support. There was a very early openmp support in gcc-4.2.1 but it wasn't very robust or complete… http://stackoverflow.com/questions/9084123/fftw3-configure-issue-for-openmp-use In the past, the openmpi package wasn't used to build support libraries so using the gcc4x compilers in openmpi was acceptable as long as the package using openmpi was prepared to build its c++ completely with the g++-fsf-4.x compiler. So you gained robust and modern openmp support in openmpi but you boxed yourself in a corner such that any code using openmpi had to be sandboxed such that it built entirely with the gcc4x compilers. Jack ps Fortunately there are very few fink packages that use openmpi so switching back to using the system compilers for mpicc/mpicxx will only require a few fink packages to get a versioned openmpi dependency and associated revision bump to force their rebuilds. On Sat, Apr 26, 2014 at 7:43 PM, Hanspeter Niederstrasser f...@snaggledworks.com wrote: On Sat, April 26, 2014 11:14 am, Jack Howarth wrote: Hanspeter, What is the logic behind making boost1.55 build against the g++-fsf-4.8 compiler instead of clang++ on 10.9 and later? By doing that, you require any program that links against boost1.55 and all of its support libraries to be built with g++-fsf-4.8. We were very careful when Mavericks landed to make sure that boost1.53 properly built against libc++ from clang++ rather than any of the libstdc++ releases (system or fsf gcc). This seems like a major regression in the packaging compared to boost1.53. I am surprised you resorted to that as the newer boost release should have even more libc++ related fixes than 1.53 did. Jack Jack, I'm currently traveling and unable to test any issues until Wednesday at the earliest, but more likely not until the weekend. I'm OK with the 10.9 conditional you put in to build with clang++ on 10.9 (plus the atomic patch). I'll be back towards the middle/end of the week to further discuss as needed. If you feel more changes are needed, please discuss on here or on #fink with dmacks since he'll understand issues that may arise from the package management end. Thanks for your help, Hanspeter -- More agile than a turtle, stronger than a mouse, nobler than a lettuce -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Fink-devel mailing list Fink-devel@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
