GCC and binutils plans for bullseye

[Matthias Klose]

Debian bullseye will be based on a gcc-10 package taken from the gcc-10 upstream
branch, and binutils based on a binutils package taken from the 2.35 branch.

I'm planning to make gcc-10 the default after gcc-10 (10.2.0) is available
(upstream targets mid July).  binutils will be updated before making the GCC
switch. The GCC 10 switch involves some minor library transitions for D, gccgo,
M2, which should be no-brainers. The gnat transition will be handled separately
by the debian Ada maintainers.

binutils should be pretty stable until the bullseye release, not planning an
update to 2.36.  GCC 10 should be updated to 10.3, or close to 10.3 (the release
date is not yet known, could be Feb 2021).

I'd like to get rid off GCC 8 and GCC 9 for the bullseye release.

Matthias

Re: GCC and binutils updates for buster

[Manuel A. Fernandez Montecelo]

2018-08-13 04:25 Paul Wise:

On Mon, Aug 13, 2018 at 1:19 AM, Manuel A. Fernandez Montecelo wrote:

2018-07-30 22:36 Adrian Bunk:


And the next burden will be if riscv64 gets added in bullseye.


[*] Unlike other arches, this one is not restricted to a single vendor
   so hardware can be annouced at any time from unexpected parties;
   still, only a few months are left.


Only a few months are left before buster, but Adrian was talking about
bullseye, which is quite a long way off.


Right, I quoted that phrase but my mind was with the Buster in the
subject.

Thanks for the correction, and sorry for the noise from my side.

--
Manuel A. Fernandez Montecelo 

Re: GCC and binutils updates for buster

[Paul Wise]

On Mon, Aug 13, 2018 at 1:19 AM, Manuel A. Fernandez Montecelo wrote:
> 2018-07-30 22:36 Adrian Bunk:
>>
>> And the next burden will be if riscv64 gets added in bullseye.
>
> [*] Unlike other arches, this one is not restricted to a single vendor
>so hardware can be annouced at any time from unexpected parties;
>still, only a few months are left.

Only a few months are left before buster, but Adrian was talking about
bullseye, which is quite a long way off.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: GCC and binutils updates for buster

[Manuel A. Fernandez Montecelo]

2018-07-30 22:36 Adrian Bunk:


And the next burden will be if riscv64 gets added in bullseye.


Not likely, I think, since for example there's almost no hardware
available for end-users to buy (or to use for buildds), and this will
probably be the case at least until the freeze [*].

Another reason is that there're missing key components that need to get
to the main upstream repos, like GDB, LLVM, Rust, JIT support for
OpenJDK, etc.

GDB is being upstreamed right now, but there's still way to go for the
rest.


[*] Unlike other arches, this one is not restricted to a single vendor
   so hardware can be annouced at any time from unexpected parties;
   still, only a few months are left.

--
Manuel A. Fernandez Montecelo 

Re: GCC and binutils updates for buster

[Adrian Bunk]

On Mon, Jul 16, 2018 at 05:59:28PM +0200, Matthias Klose wrote:
>...
>  - armel: The armv4t default isn't used very much anymore,

The baseline is armv5te since last year.

> and we had issues in the past.

Could you elaborate on that?

The latest major issue I am aware of was about #727621 and the backport 
of the fix.[1] #727621 was not even a regression, this was new 
functionality accidentally not provided by gcc on armel.

>  - armhf: While arm-linux-gnueabihf is not explicitly listed as a primary
>architecture, I'm told that the arm-linux-armeabi triplet covers the
>hard float variants as well.
> 
>  - ppc64el: Not documented as primary architecture, but according to the
>backend maintainers the powerpc64-linux-gnu triplet includes the le 
> variant.
> 
>  - mips*: There is no support for any mips-linux target either as a primary
>or secondary release architecture (only bare metal), which matches the
>experience with mips specific issues for the past Debian releases.
> 
> I understand that port maintainers want to have their port included as a 
> release
> architecture, however it becomes a burden if neither the upstream nor the 
> Debian
> port maintainers can keep up with the general upstream development. Maybe we
> need something in between the alternatives of being a release arch or not,
> having the benefit of packages in testing/stable, but not being supported in a
> release.

Your theoretical discussion based on upstream definitions misses which 
architectures actually have a proven track record of frequent toolchain 
problems in recent years.

Any discussion about real problems has to include arm64 as a prime 
candidate for demotion - no matter the upstream definition.

We even had last-minute toolchain regressions like #863152, which means 
that we cannot rebuild some packages we ship for arm64 in stretch.
Such regressions are a problem both for security support and licence reasons.

The root problem for most actual breakages is that regresssions are 
usually not in boring stale old code nobody touches - regressions
tend to be in sexy new code that is under heavy development.

arm64 and mips64el are the most recent of the architectures in stretch.
There is a lot of upstream toolchain development happening for arm64.

These are the reasons why arm64 and mips64el have been a burden
in recent years.

And the next burden will be if riscv64 gets added in bullseye.

I do not have the impression that this burden is unmanageable, but if 
you disagree the actual discussion you have to start is about delaying
the inclusion of ports for new hardware in a Debian stable release.

> Matthias
>...

cu
Adrian

[1] Reminds me that I have to check which Breaks are missing for that.

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

Re: GCC and binutils updates for buster

[Sebastian Andrzej Siewior]

On 2018-07-16 17:59:28 [+0200], Matthias Klose wrote:
> architectures.  Some notes on other candidates for release architectures:
> 
>  - armel: The armv4t default isn't used very much anymore, and we had
>issues in the past.

Would things get better with armv5te as default or is the lack of FPU
the actual problem?

> Matthias

Sebastian

GCC and binutils updates for buster

[Matthias Klose]

GCC 8 is available in testing/unstable, and upstream is approaching the first
point release.  I am planning to make GCC 8 the default at the end of the week
(gdc and gccgo already point to GCC 8).  Most runtime libraries built from GCC
are already used in the version built from GCC 8, so I don't expect runtime
incompatibilities anymore.  There is one more transistion involved, bumping the
libgfortran version.

A pre-release version of binutils 2.31 is in testing now, and the final 2.31
release in unstable.

These are the major versions for the upcoming buster release, still planning
updates to a potential GCC 8.3.0 (estimated Jan 2019) release and binutils
2.31.1 release, or doing equivalent updates from the release branches.

There are still a bunch of build failures triggered by GCC 8 [1], so fixing
these should get some priority now. See [2] for changes in GCC 8, and the
porting guide [3].  I'll be at DebCamp for the second half of the week, and at
DebConf, so if there is interest for bug squashing sessions, feel free to grab
me, and we can schedule such sessions on a short notice.

GCC 5 and GCC 6 are going away, and I am planning the same with GCC 7 as soon as
there are upstream kernel and glibc releases which are released after the GCC
8.1.0 release from April.

The Debian release team lists toolchain support for our release architectures,
and according to [4], the amd64, i386, armel, armhf, arm64 architectures are
supported as primary architectures, and s390x is supported as a secondary
architectures.  Some notes on other candidates for release architectures:

 - armel: The armv4t default isn't used very much anymore, and we had
   issues in the past.

 - armhf: While arm-linux-gnueabihf is not explicitly listed as a primary
   architecture, I'm told that the arm-linux-armeabi triplet covers the
   hard float variants as well.

 - ppc64el: Not documented as primary architecture, but according to the
   backend maintainers the powerpc64-linux-gnu triplet includes the le variant.

 - mips*: There is no support for any mips-linux target either as a primary
   or secondary release architecture (only bare metal), which matches the
   experience with mips specific issues for the past Debian releases.

I understand that port maintainers want to have their port included as a release
architecture, however it becomes a burden if neither the upstream nor the Debian
port maintainers can keep up with the general upstream development. Maybe we
need something in between the alternatives of being a release arch or not,
having the benefit of packages in testing/stable, but not being supported in a
release.

Matthias

[1]
http://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=ftbfs-gcc-8;users=debian-...@lists.debian.org
[2] https://gcc.gnu.org/gcc-8/changes.html
[3] https://gcc.gnu.org/gcc-8/porting_to.html
[4] https://gcc.gnu.org/gcc-8/criteria.html



signature.asc
Description: OpenPGP digital signature

Re: Reply headers vs. in-mail requests (was Re: Bad news to CUDA applications (was: Re: GCC 6 & binutils for the Debian stretch release))

[Jonathan Dowland]

On Fri, Jul 01, 2016 at 09:04:50AM -0400, The Wanderer wrote:
> I'm pretty sure there is no header setting which will make this fully
> automatic.

I have been suitably admonished off-list for starting this $DEITY-awful
sub-topic once again. Consider myself chastened!


-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Reply headers vs. in-mail requests (was Re: Bad news to CUDA applications (was: Re: GCC 6 & binutils for the Debian stretch release))

[The Wanderer]

On 2016-07-01 at 08:43, Jonathan Dowland wrote:

> On Fri, Jul 01, 2016 at 06:07:27AM +, lumin wrote:
> 
>> (please keep me in CC list)
> 
> I suggest setting the headers to make this automatic rather than
> asking people to remember to do it :)

I'm pretty sure there is no header setting which will make this fully
automatic.

For one thing, he can only control header settings on mails which he
sends, not on mails which other people send in reply to those mails. If
he wants to be CCed on replies to those replies, as far as I know there
is no header which he can set which will make that happen.

For another thing, some replying practices will ignore such headers.

I normally reply to list mail using Thunderbird/Icedove's "Reply to
List" button, which addresses the reply only to the mailing list itself,
ignoring any headers which may be set to direct replies elsewhere. I do
this because otherwise the reply tends to be directed either to the
original sender rather than to the list (with "Reply", in the absence of
Reply-To set to the list address), or to all recipients (with "Reply
All"), depending on what headers are present - and IMO neither of those
is the correct default.

The presence of a comment such as this one informs me that I may want to
vary that practice in a given case. (I haven't done so in this case
since this mail is no longer on the topic which he raised, so I don't
have good reason to expect him to be interested in it.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Bad news to CUDA applications (was: Re: GCC 6 & binutils for the Debian stretch release)

[Jonathan Dowland]

On Fri, Jul 01, 2016 at 06:07:27AM +, lumin wrote:
> (please keep me in CC list)

I suggest setting the headers to make this automatic rather than asking
people to remember to do it :)

> I'm pointing out a BIG problem introduced by stretch's GCC-6-only plan.
> 
> In brief CUDA 8.0~RC fails to work with GCC-6, this conclusion
> comes from my local Caffe build log as attached. 
> That is to say, after GCC-6 transition *ALL* packages depending
> on cuda will get removed from stretch due to FTBFS.

Technically, these packages are/were never in Stretch per se, because
they're all contrib/non-free.

-- 
Jonathan Dowland
Please do not CC me, I am subscribed to the list.


signature.asc
Description: Digital signature

Re: Bad news to CUDA applications (was: Re: GCC 6 & binutils for the Debian stretch release)

[Vincent Danjean]

Le 01/07/2016 à 08:51, lumin a écrit :
> 
> Releated bug on ArchLinux:
> https://bugs.archlinux.org/task/49272?project=5=12602
> 
> There are some hacks but none of them seems to be "an actual solution
> to packaging".

Personally, I would create a gcc/g++ wrapper in order to capture
the exact options passed by nvcc and to record the input file(s).
  Then, I would try to see how things can be fixed manually (ie
find options to add to the real gcc call to compile successfully).
  And, if nvidia does not update nvcc (and if the previous step
was successful), I would create a wrapper around nvcc that force
to call a gcc-wrapper (perhaps just redefining PATH would be enough)
that would add fix-flags to a real gcc call.

  Regards,
Vincent

> On Fri, 2016-07-01 at 06:07 +, lumin wrote:
>> Hi all,
>> (please keep me in CC list)
>>
>> I'm pointing out a BIG problem introduced by stretch's GCC-6-only plan.
>>
>> In brief CUDA 8.0~RC fails to work with GCC-6, this conclusion
>> comes from my local Caffe build log as attached. 
>> That is to say, after GCC-6 transition *ALL* packages depending
>> on cuda will get removed from stretch due to FTBFS.
>>
>> I don't expect Nvidia to release CUDA 8.5 before the stretch
>> freeze date (Q1 2017), i.e. even a freeze-exception against
>> cuda might not save this situation. So all maintainers maintaining
>> CUDA application packages have to face this harsh condition.
>> Do you have any solution to this problem?
>>
>> Besides, I cc'ed 2 nvidia guys with a hope that they can provide
>> some helpful information.
> 
> 


-- 
Vincent Danjean   GPG key ID 0xD17897FA vdanj...@debian.org
GPG key fingerprint: 621E 3509 654D D77C 43F5  CA4A F6AE F2AF D178 97FA
Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html
APT repo:  deb http://people.debian.org/~vdanjean/debian unstable main

Re: Bad news to CUDA applications (was: Re: GCC 6 & binutils for the Debian stretch release)

[lumin]

Releated bug on ArchLinux:
https://bugs.archlinux.org/task/49272?project=5=12602

There are some hacks but none of them seems to be "an actual solution
to packaging".

On Fri, 2016-07-01 at 06:07 +, lumin wrote:
> Hi all,
> (please keep me in CC list)
> 
> I'm pointing out a BIG problem introduced by stretch's GCC-6-only plan.
> 
> In brief CUDA 8.0~RC fails to work with GCC-6, this conclusion
> comes from my local Caffe build log as attached. 
> That is to say, after GCC-6 transition *ALL* packages depending
> on cuda will get removed from stretch due to FTBFS.
> 
> I don't expect Nvidia to release CUDA 8.5 before the stretch
> freeze date (Q1 2017), i.e. even a freeze-exception against
> cuda might not save this situation. So all maintainers maintaining
> CUDA application packages have to face this harsh condition.
> Do you have any solution to this problem?
> 
> Besides, I cc'ed 2 nvidia guys with a hope that they can provide
> some helpful information.

Bad news to CUDA applications (was: Re: GCC 6 & binutils for the Debian stretch release)

[lumin]

Hi all,
(please keep me in CC list)

I'm pointing out a BIG problem introduced by stretch's GCC-6-only plan.

In brief CUDA 8.0~RC fails to work with GCC-6, this conclusion
comes from my local Caffe build log as attached. 
That is to say, after GCC-6 transition *ALL* packages depending
on cuda will get removed from stretch due to FTBFS.

I don't expect Nvidia to release CUDA 8.5 before the stretch
freeze date (Q1 2017), i.e. even a freeze-exception against
cuda might not save this situation. So all maintainers maintaining
CUDA application packages have to face this harsh condition.
Do you have any solution to this problem?

Besides, I cc'ed 2 nvidia guys with a hope that they can provide
some helpful information.


caffe_buildlog_nvcc8_gcc6_failure.txt.gz
Description: application/gzip


signature.asc
Description: This is a digitally signed message part

Re: GCC 6 & binutils for the Debian stretch release

[James McCoy]

On Fri, Jun 24, 2016 at 04:03:44PM +0200, Paul Wise wrote:
> On Fri, Jun 24, 2016 at 3:46 PM, Matthias Klose wrote:
> 
> > As announced a year ago [1], GCC 6 will be the default GCC for the Debian
> > stretch release.  GCC 6 is now available in testing, and can be made the 
> > default
> > by installing the gcc/g++ packages from experimental.  Known build failures 
> > are
> > reported at [2] seen on amd64.  Build failures for more architectures (but 
> > done
> > for Ubuntu packages) can be seen at [3].  Please help fixing these issues in
> > testing/unstable. Some help how to approach build issues can be found at 
> > [4].
> 
> Could we have a dd-list of people who will have to fix a bug for this
> transition?

Attached, based on “bts select users:debian-...@lists.debian.org
tag:ftbfs-gcc-6 status:open”.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB
"Adam C. Powell, IV" 
   elmerfem (U)
   oce (U)

"Natural Language Processing, Japanese" 

   chasen

A. Maitland Bottoms 
   sdrangelove
   splat (U)

Adrian Knoth 
   calf (U)
   jackd2 (U)
   libdrumstick (U)

Agustin Henze 
   crrcsim

Aigars Mahinovs 
   re

Alan Baghumian 
   dasher (U)

Alastair McKinstry 
   ggcov

Alessio Treglia 
   ams (U)
   composite (U)
   crtmpserver (U)
   din (U)
   klick (U)
   libdrumstick (U)
   sndobj (U)
   terminatorx (U)

Alexander GQ Gerasiov 
   gxneur
   xneur

Alexey Bychko 
   percona-xtrabackup (U)

Ana Beatriz Guerrero Lopez 
   mstflint (U)

Andreas Tille 
   adun.app (U)
   blitz++ (U)
   disulfinder (U)
   hyphy (U)
   idba (U)
   libbpp-core (U)
   libgtextutils (U)
   libmems (U)
   liborigin2 (U)
   librg-blast-parser-perl (U)
   librostlab-blast (U)
   mrs (U)
   murasaki (U)
   prime-phylo (U)
   proftmb (U)
   qwtplot3d (U)
   rate4site (U)
   relion (U)
   sitplus (U)
   sofa-framework (U)
   swarm-cluster (U)
   yaml-cpp (U)

Andres Mejia 
   crtmpserver (U)

Andrew Bartlett 
   samba (U)

Andrew Pollock 
   protobuf (U)

Andrew Shadura 
   postbooks (U)

Andriy Beregovenko 
   crtmpserver (U)

Ansgar Burchardt 
   dune-grid (U)

Anton Gladky 
   avogadro (U)
   esys-particle (U)
   oce (U)
   paraview (U)

Anuradha Weeraman (anu) 
   ncc

Apollon Oikonomopoulos 
   mongodb (U)

Arnout Engelen 
   libdrumstick (U)

Aron Xu 
   fcitx-unikey (U)
   librime (U)
   libucimf (U)

Aron Xu 
   ucimf-openvanilla (U)

Athena Capital Research 
   pion

Balint Reczey 
   dasher (U)
   libcec-platform (U)
   libv8-3.14 (U)

Barak A. Pearlmutter 
   colpack (U)
   ivtools
   mldemos

Barry deFreese 
   bloboats (U)

Barry deFreese 
   libclaw (U)

Bastian Blank 
   thin-provisioning-tools (U)
   xen (U)

Bdale Garbee 
   splat

Ben Burton 
   regina-normal

Ben Hutchings 
   sgt-puzzles

Benda Xu 
   scim (U)

Benjamin Drung 
   audacity (U)

Bernd Zeimetz 
   open-vm-tools

Boris Pek 
   elmerfem (U)

Bradley Smith 
   galib

Bruno "Fuddl" Kleinert 
   scorched3d (U)

Bryan Sutula 
   openhpi

Carlo Segre 
   fityk
   objcryst-fox

Ceph Maintainers 
   ceph

ChangZhuo Chen (陳昌倬) 
   libucimf (U)

Charles Plessy 
   libgtextutils (U)

Chow Loong Jin 
   libzen
   slic3r (U)
   tinyxml2

Chris Butler 
   libcgicc

Chris Coulson 
   mozjs

Christian M. Amsüss 
   hyperrogue (U)

Christian Perrier 
   samba (U)

Christian Stalp 
   free42-nologo

Christoph Egger 
   fife (U)
   irrlicht (U)

Christophe Prud'homme 
   paraview (U)

Christophe Trophime 
   blitz++ (U)

Cleto Martín 
   zthreads

Craig Small 
   mudlet

CrossWire Packages 
   sword

Cédric Boutillier 
   gfan (U)

Daigo Moriwaki 
   gpsshogi
   libosl

Damyan Ivanov 
   gbgoffice
   hyperrogue (U)

Daniel Glassey 
   clucene-core 

Re: BOOST-1.60 compiled with g++6, [Was: GCC 6 & binutils for the Debian stretch release]

[Dimitri John Ledkov]

Hello,

On 27 June 2016 at 11:37, Dimitri John Ledkov  wrote:
> Hello,
>
> On 26 June 2016 at 11:31, Gert Wollny  wrote:
>> Hi all,
>>
>> considering that BOOST 1.60 changes the ABI when compiled with -std >=
>> c++11 versus -std <= c++03 (cf. [1]) , and that g++-6 defaults to
>> -std=c++14 it would probably be a good idea if a boost >= 1.60 version
>> compiled with g++6 would be available from experimental when the bug
>> squashing starts.
>
> gnu/c++03 -> gnu/c++11 was special as there was libstdc++ library ABI break.
>
> As far as I am aware gcc6 changes the default _standard_ version to
> gnu++14, however it remains binary compatible with gnu/c++11 libstdc++
> ABI.
>
> In other words, please do not assume that we need to bump ABI across
> the board the way we did when migrating to libstdc++ 11 abi.
>
> I will do more checking, but my understanding is that current boost
> should be fit for purpose for either gnu++11 or gnu++14 standard
> builds with c++11 libstdc++ ABI. Debian no longer supports libstdc++
> c++03 abi.

However above seems to contradict my understanding of the situation in
May 2016 lol =) Back then I did believe that boost needs to be
rebuild.

*sigh* i'm really not in a rational state of mind at the moment. I'll
try to dig into it during Debconf 2016, when I'm away from the current
politics in my country.

-- 
Regards,

Dimitri.

Re: BOOST-1.60 compiled with g++6, [Was: GCC 6 & binutils for the Debian stretch release]

[Dimitri John Ledkov]

Hello,

On 26 June 2016 at 11:31, Gert Wollny  wrote:
> Hi all,
>
> considering that BOOST 1.60 changes the ABI when compiled with -std >=
> c++11 versus -std <= c++03 (cf. [1]) , and that g++-6 defaults to
> -std=c++14 it would probably be a good idea if a boost >= 1.60 version
> compiled with g++6 would be available from experimental when the bug
> squashing starts.

gnu/c++03 -> gnu/c++11 was special as there was libstdc++ library ABI break.

As far as I am aware gcc6 changes the default _standard_ version to
gnu++14, however it remains binary compatible with gnu/c++11 libstdc++
ABI.

In other words, please do not assume that we need to bump ABI across
the board the way we did when migrating to libstdc++ 11 abi.

I will do more checking, but my understanding is that current boost
should be fit for purpose for either gnu++11 or gnu++14 standard
builds with c++11 libstdc++ ABI. Debian no longer supports libstdc++
c++03 abi.

-- 
Regards,

Dimitri.

BOOST-1.60 compiled with g++6, [Was: GCC 6 & binutils for the Debian stretch release]

[Gert Wollny]

Hi all, 

considering that BOOST 1.60 changes the ABI when compiled with -std >=
c++11 versus -std <= c++03 (cf. [1]) , and that g++-6 defaults to 
-std=c++14 it would probably be a good idea if a boost >= 1.60 version
compiled with g++6 would be available from experimental when the bug
squashing starts. 

Best, 
Gert 

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=823978

Re: GCC 6 & binutils for the Debian stretch release

[Paul Wise]

On Fri, Jun 24, 2016 at 3:46 PM, Matthias Klose wrote:

> As announced a year ago [1], GCC 6 will be the default GCC for the Debian
> stretch release.  GCC 6 is now available in testing, and can be made the 
> default
> by installing the gcc/g++ packages from experimental.  Known build failures 
> are
> reported at [2] seen on amd64.  Build failures for more architectures (but 
> done
> for Ubuntu packages) can be seen at [3].  Please help fixing these issues in
> testing/unstable. Some help how to approach build issues can be found at [4].

Could we have a dd-list of people who will have to fix a bug for this
transition?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: gcc and binutils

[Ian Jackson]

Bernd Eckenfels writes (gcc and binutils):
 ist it possile that on a fresh new install gcc is installed before binutils
 is installed, and therefore fail to configure? If I run configure afterwards
 everything is fine. Will dpkg install a package first if it sees that other
 ones depend on it?

Err, I don't quite understand the question.  The answer to your first
sentence is `no, it shouldn't be possible'.

See the draft programmers' manual for details of exactly how things
happen.

Ian.

gcc and binutils

[Bernd Eckenfels]

Hi,

ist it possile that on a fresh new install gcc is installed before binutils
is installed, and therefore fail to configure? If I run configure afterwards
everything is fine. Will dpkg install a package first if it sees that other
ones depend on it?

Greetings
Bernd
-- 
  (OO)  -- [EMAIL PROTECTED] --
 ( .. )  [EMAIL PROTECTED],ka.sub.org}  http://home.pages.de/~eckes/
  o--o *plush*  2048/A2C51749  [EMAIL PROTECTED]  +4972573817  *plush*
(OO)   If privacy is outlawed only Outlaws have privacy