Source: gcc-4.7
Version: 4.7.1-1
Severity: normal
Hi,
one of the (many many many) packages in ia32-libs has a dependency on
cpp-4.7. Please mark the cpp-4.7 package as Multi-Arch: foreign so
that the dependency can be fullfilled by the native architecture.
More info:
Matthias Klose d...@debian.org writes:
On 11/19/2011 11:42 PM, Ben Hutchings wrote:
The i386 architecture was the first in Linux and in Debian, but we have
long since dropped support for the original i386-compatible processors
and now require a minimum of a 486-class processor.
I think it
Guillem Jover guil...@debian.org writes:
Hi!
On Sat, 2011-11-19 at 22:42:11 +, Ben Hutchings wrote:
The i386 architecture was the first in Linux and in Debian, but we have
long since dropped support for the original i386-compatible processors
and now require a minimum of a 486-class
Package: gcc-defaults
Version: 1.96
Severity: normal
Hi,
building gcc defaults I get:
dh_fixperms -i
dh_python2 -plibgcj-common
make: dh_python2: Command not found
make: *** [binary-indep] Error 127
dh_python2 is part of python and I don't see a Build-Depends: python in
the source.
MfG
Hi,
I just noticed that icc (intel C/C++ compiler) will no longer work in
Squeeze because lbstdc++5 (from gcc-3.3) was removed. Same goes for Civ
CTP or Heroes and probably a lot of other old games and 3rd party
software in general.
Is there any chance of getting libstdc++5 back in oldlibs?
MfG
Package: gcc-4.3
Version: 4.3.4-1
Severity: wishlist
Hi,
I'm trying to build a cross-compiler for i486-linux-gnu for amd64
Debian and it fails. I know, I know, there is gcc -m32. But I need to
test cross-compiling and I don't have an arm cpu to test with.
I followed the instructions on
Hi,
small update to the bug report.
The libc6-i386 package screwed up the transition by forgetting to
delete the /lib32 and /usr/lib32 in preinst. So on upgrades all files
remain under /emul/ia32-linux/ and the only thing that changes is the
way dpkg sees them.
So you don't need a Pre-Depends
Matthias Klose d...@debian.org writes:
Goswin von Brederlow schrieb:
Hi,
small update to the bug report.
The libc6-i386 package screwed up the transition by forgetting to
delete the /lib32 and /usr/lib32 in preinst. So on upgrades all files
remain under /emul/ia32-linux/ and the only
Hi,
after talking it through on irc Clint Adams decided to ignore the
current broken transition introduced in libc6-i386 2.9-14 and to do it
right in 2.9-18. So far only fakeroot, gnu-efi and gcc-4.4 have
uploaded a new version placing files in /usr/lib32 while all the
others still block updates.
Arthur Loiret aloi...@debian.org writes:
The missing dir separator has been added, the fix is in our svn. Now a
few comments about your bug report:
2009/5/8, Goswin Brederlow goswin-...@web.de:
# Broken path. Missing a '/'?
Yes, fixed.
* Duplicate entry after canonicalize
Not an issue.
Hector Oron hector.o...@gmail.com writes:
Hello,
The toolchain does not yet look in all the right places. Neither for
the multiarch nor the corss-compile way of putting the prefix. It is
in a state where both ways are used and neither is complete enough for
a full system.
So, would it be
Hector Oron hector.o...@gmail.com writes:
Hello,
, and there is generally no need to
install anything but libraries and headers into /usr/triplet -- so I
don't think there is a pressing need to replicate a filesystem hierarchy
standard below a triplet directory.
True, however, that is
Simon Richter s...@debian.org writes:
Hi,
, since
they have entirely different objectives
Not entirely different - the objective for the packaging tools is
actually the same, to have packages install cleanly without changes on
systems with a different architecture triplet.
I'm not sure
Neil Williams codeh...@debian.org writes:
On Wed, 11 Mar 2009 14:50:19 +0100
Goswin von Brederlow goswin-...@web.de wrote:
[*]
I have been looking lately into making some cross toolchain
improvements, one of them will be to change to a sysrooted cross
toolchain, but the current
Neil Williams codeh...@debian.org writes:
On Thu, 12 Mar 2009 10:31:03 +0100
Goswin von Brederlow goswin-...@web.de wrote:
I thought mulitarch wanted:
(this is making a lot more sense now.)
So, updating:
/usr/
|-- include/
| `-- $arch-linux-gnu/
| `-- foo.h
Request was from Matthias Klose d...@cs.tu-berlin.de to
cont...@bugs.debian.org. (Wed, 18 Jun 2008 19:15:09 GMT) Full text and rfc822
format available.
Changed Bug title to `gcc: please add support for multiarch' from `binutils:
please add support for multiarch'. Request was from Goswin von Brederlow
Hector Oron hector.o...@gmail.com writes:
Hello,
I have been talking with Guillem on IRC, he has point me to a
reference[1], that might be useful.
[1] http://lackof.org/taggart/hacking/multiarch/
Regards
That is a nice non Debian specific writeup (i.e. it doesn't go into
any of the
Hector Oron hector.o...@gmail.com writes:
Hello,
[*]
I have been looking lately into making some cross toolchain
improvements, one of them will be to change to a sysrooted cross
toolchain, but the current layout we are using by dpkg-cross installs
relevant bits under:
Ron Garret [EMAIL PROTECTED] writes:
Package: gcc, ia32-libs
Version: 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
I am getting the oft-reported skipping incompatible /usr/bin/../lib/
libc.a when searching for -lc problem when trying to compile 32 bit
binaries on a 64-bit machine.
# Automatically generated email from bts, devscripts version 2.10.28
reassign 498744 gcc
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: g++-4.3
Version: 4.3.1-5
Severity: normal
Hi,
I recently run into a bug with the following code (simplified to the
essentials):
#include cstring
void foo(const char *path) {
char *filename = rindex(path, '/');
*filename = 0;
++filename;
}
This clearly violates the constness of
Matthias Klose [EMAIL PROTECTED] writes:
Goswin von Brederlow writes:
Matthias Klose [EMAIL PROTECTED] writes:
Goswin von Brederlow writes:
Hi,
I believe the gcc source already has a patch for multiarch include and
library
directories but they are deactiveated in rules.defs
Matthias Klose [EMAIL PROTECTED] writes:
Goswin von Brederlow writes:
Hi,
I believe the gcc source already has a patch for multiarch include and
library
directories but they are deactiveated in rules.defs.
Can you comment on the functionality of them?
no, this one is obsolete
Hi,
I believe the gcc source already has a patch for multiarch include and library
directories but they are deactiveated in rules.defs.
Can you comment on the functionality of them?
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble?
Package: gcc-4.3
Version: 4.3.1-2
Severity: normal
Hi,
when linking with 'gcc -m32 -lfoo' the library search path differs for
amd64 and i386.
On i386 you have the right directory:
[pid 4966] stat64(/usr/i486-linux-gnu/lib/libfoo.so, 0xffacca30) = -1 ENOENT
(No such file or directory)
On
# Automatically generated email from bts, devscripts version 2.10.30
reassign 369064 gcc-4.3
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
reassign 45 gcc-3.3
thanks
[EMAIL PROTECTED] (Debian Bug Tracking System) writes:
Processing commands for [EMAIL PROTECTED]:
reassign 45 ia32-libs
Bug#45: 32bit version of library not distributed under amd64 architecture
Bug reassigned from package `libstdc++5' to `ia32-libs'.
Hi,
sorry for the CC. I started to report the bug of an ICE but while
testing manual compile (takes about 10m for the file). As it turned
out the problem did seem to be hardware/os releated, unreproducible,
as oppsoed to a gcc bug and I forgot to restart reportbug without the
CC to you.
Please
Matthias Klose [EMAIL PROTECTED] writes:
Stuart Anderson writes:
On Sat, 11 Feb 2006, Aurelien Jarno wrote:
Also, I am ready to give some help there. I am first trying to build the
gcc and glibc packages on a mips, but I face a chicken and egg problem
here. Does anybody already have
Harald Dunkel [EMAIL PROTECTED] writes:
Unpacking ia32-libs (from .../ia32-libs_1.3.0.0.1.gcc4_amd64.deb) ...
Setting up lib32gcc1 (4.0.0-1) ...
Setting up ia32-libs (1.3.0.0.1.gcc4) ...
Version 1.3 was broken, version 1.4 is fixed. Please upgrade.
MfG
Goswin
--
To UNSUBSCRIBE,
Harald Dunkel [EMAIL PROTECTED] writes:
Goswin von Brederlow wrote:
Version 1.3 was broken, version 1.4 is fixed. Please upgrade.
Still no change:
[EMAIL PROTECTED]:harri 1003} ls -lhd /usr/lib32
ls: /usr/lib32: No such file or directory
[EMAIL PROTECTED]:harri 1003} apt-get install
Laurent Bonnaud [EMAIL PROTECTED] writes:
Which version of ia32-libs-dev was installed during the build?
The latest version available in sid:
ii ia32-libs-dev 1.4 ia32 development libraries
and headers for use on ia32/ia6
Please make sure you have:
[EMAIL
Thiemo Seufer [EMAIL PROTECTED] writes:
I could patch each package as I go, but I really want to know if there is
any effort to migrate to GCC 3.4, as there a lot more c++ packages
with similarly cryptic errors.
Currently the main focus is on releasing sarge, with gcc-3.3 as default
Laurence Darby [EMAIL PROTECTED] writes:
On Tue, 1 Mar 2005, Goswin von Brederlow wrote:
Laurence Darby [EMAIL PROTECTED] writes:
It's my task to compile a complete Debian distribution from source. The
main goal is to test our version of the GCC compiler, SDE, which is based
on 3.4.2
Laurence Darby [EMAIL PROTECTED] writes:
Hi,
It's my task to compile a complete Debian distribution from source. The
main goal is to test our version of the GCC compiler, SDE, which is based
on 3.4.2, and has more tuning/optimisations for the MIPS architecture. The
second goal is to be
[EMAIL PROTECTED] (Debian Bug Tracking System) writes:
This is an automatic notification regarding your Bug report
#268929: libffi2-dev: [amd64] Wrong libdir='/usr/lib./lib64',
which was filed against the libffi2-dev package.
It has been closed by one of the developers, namely
Matthias
Hi,
the test condition for amd64 is reversed in the last patch which
breaks amd64 and possibly sparc and s390.
Here is the same patch with reversed test.
MfG
Goswin
==
diff -Nurd gcc-3.3-3.3.4/debian/rules2
Hi,
welcome to our little rolercoaster. Lowering the priority again.
Steve Langasek verified this on sparc and said that the sparc sablevm
package was build with the broken libffi2-dev package. But unlike the
previous builds with '/usr/lib/.' or '/usr/lib/../lib64' this time
libtool did not mess
Package: libffi2-dev
Version: 1:3.3.4-6sarge1.2
Severity: grave
Justification: renders package unusable
Hi,
I compiled the gcc-3.3 from t-p-u for amd64 and noticed that libdir is
now broken:
# Directory that this library needs to be installed in:
libdir='/usr/lib./lib64'
I checked the i386
Hi,
while working on a patch for this I checked sparc for the 32/64 bit
case and found the same error as on amd64 there, hence the change back
to grave.
On sparc:
== ./usr/lib/gcc-lib/sparc-linux/3.3.4/libobjc.la ==
libdir='/usr/lib./lib'
== ./usr/lib/gcc-lib/sparc-linux/3.3.4/libobjc_gc.la ==
Scott James Remnant [EMAIL PROTECTED] writes:
On Thu, 2004-08-26 at 02:48 -0700, Debian Bug Tracking System wrote:
then libtool should be fixed. there is no documented requirement that
the path has to be normalized.
While there's no specifically documented requirement, there is a common
Matthias Klose [EMAIL PROTECTED] writes:
then libtool should be fixed. there is no documented requirement that
the path has to be normalized.
On amd64 you get
libdir='/usr/lib/../lib64'
even normalized that would be
libdir='/usr/lib64'
which is still wrong since libffi3 only has
Scott James Remnant [EMAIL PROTECTED] writes:
On Thu, 2004-08-26 at 13:39 +0200, Goswin von Brederlow wrote:
Scott James Remnant [EMAIL PROTECTED] writes:
On Thu, 2004-08-26 at 02:48 -0700, Debian Bug Tracking System wrote:
then libtool should be fixed. there is no documented
Matthias Klose [EMAIL PROTECTED] writes:
Goswin Brederlow writes:
libffi.la has the following libdir:
libdir='/usr/lib/../lib'
That cuases libtool to add the rpath option when linking against the
library which in turn prevents shlibs to work (since no package
contains
Peter Cordes [EMAIL PROTECTED] writes:
On Wed, Aug 04, 2004 at 05:42:30PM -0400, Daniel Jacobowitz wrote:
First, what I'm suggesting: two new packages for sarge and one modified
package. They would allow 64-bit applications using a small set of standard
libraries to run on an otherwise i386
Daniel Jacobowitz [EMAIL PROTECTED] writes:
I spent some time talking with the glibc maintainers about this. These
are all my own opinions, but the others seemed to agree with me.
I think this would be a very good idea.
On Wed, Jul 28, 2004 at 09:12:19PM +0200, Goswin von Brederlow wrote
2004-06-21 23:06:20.0
+
@@ -1,3 +1,9 @@
+gcc-snapshot (20040620-1.0.0.1.pure64) unstable; urgency=low
+
+ * No multilib for pure64
+
+ -- Goswin von Brederlow [EMAIL PROTECTED] Tue, 22 Jun 2004 01:06:32 +0200
+
gcc-snapshot (20040620-1) unstable; urgency=low
* CVS 20040620, taken
Matthias Klose [EMAIL PROTECTED] writes:
libgnat first has to be ported to build the shared library. gcc-3.4
already has this support. I won't add new packages to gcc-3.3 before
sarge is released.
I managed to add a few -fPIC to gcc so libgnat.a is build with
-fPIC. After that the ada
Andreas Jochens [EMAIL PROTECTED] writes:
tags 252742 + patch
merge 252742 252699
On 04-Jun-04 21:40, Goswin von Brederlow wrote:
sorry to bother you again. We managed to bootstrap gnats with a gentoo
gnats and then rebuilding gcc with itself again. So we now have a
gnats-3.3 amd64 package
Package: gnat-3.3
Version: 1:3.3.4-1
Severity: normal
Hi,
you probably can't do anything about but maybe you can check if the same
happens on other archs, ia64 for example.
It seems like libgnat is build without -fPIC
O|114.41|gnatgcc -o debian/tmp/libgnadeodbc.so.1.5.1 -shared -fPIC
Package: gcc-3.3
Version: 1:3.3.3-9
Severity: normal
Hi,
sorry to bother you again. We managed to bootstrap gnats with a gentoo
gnats and then rebuilding gcc with itself again. So we now have a
gnats-3.3 amd64 package in archive to supply the build-depends to build gnats.
Please add gnats for
John Goerzen [EMAIL PROTECTED] writes:
Putting gcc-3.4 in there itself is not a big deal. Updating gcc such
that gcc, g++, and friends call version 3.4 is a little different,
especially for C++. We also can't necessarily call it good, since some
packages may be hardcoded for specific
Package: gcc-snapshot
Severity: serious
Justification: no longer builds from source
Compiling gcc-snapshot in a sid chroot (from yesterday 10 May 2004) fails
with the following:
cc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../src/libiberty/../include -W -Wall
-Wtraditional -pedantic
53 matches
Mail list logo
