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: http://wiki.debian.org/Relea
Matthias Klose 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 is ti
Guillem Jover 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 processor.
>>
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 http://em
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.
Matthias Klose 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
>>
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 af
Arthur Loiret 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 :
>> # Broken path. Missing a '/'?
>
> Yes, fixed.
>
>> * Duplicate entry after canonicalize
>
> Not an issue.
>
>> ! Path for the wr
Hector Oron 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 fine to se
Hector Oron writes:
> Hello,
>
, and there is generally no need to
install anything but libraries and headers into /usr/ -- so I
don't think there is a pressing need to replicate a filesystem hierarchy
standard below a triplet directory.
>>
>>> True, however, that is not a su
Simon Richter 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 sur
Hector Oron 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 implementation de
wontfix Request was from Matthias Klose 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 Bre
Neil Williams writes:
> On Thu, 12 Mar 2009 10:31:03 +0100
> Goswin von Brederlow wrote:
>
>> > I thought mulitarch wanted:
>
> (this is making a lot more sense now.)
>
> So, updating:
>
>> > /usr/
>> > |-- include/
>> >
Neil Williams writes:
> On Wed, 11 Mar 2009 14:50:19 +0100
> Goswin von Brederlow wrote:
>
>> >
>> > [*]
>> > I have been looking lately into making some cross toolchain
>> > improvements, one of them will be to change to a sysrooted cross
>&g
Hector Oron 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:
> /{include,bin,lib,lib64}
> M
# 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]
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 machi
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
void foo(const char *path) {
char *filename = rindex(path, '/');
*filename = 0;
++filename;
}
This clearly violates the constness of path but
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
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 com
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 amd
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? Con
# 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-lib
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 ig
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 a
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 dir
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
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:
[EMA
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 defau
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
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
[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 gcc-3.3-3.3.
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
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 <
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 pac
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 /u
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:
>> >
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
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
/usr/l
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 otherwi
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 +02
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 20
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 p
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
debian/tm
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.
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 am
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 ../../src/libibe
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 specif
53 matches
Mail list logo