Bug#1052008: gm2-13 Cannot Find Its Libraries At Link Time
Package: gm2-13 Version: 13.2.0-4 Severity: important X-Debbugs-Cc: ron163...@startmail.com Dear Maintainer, Since the upgrade from gm2-12 to gm2-13, the link step fails: /usr/bin/gm2 -fpim -flibs=m2pim,m2cor,m2iso -o topsort_m2 ../topsort.mod FAILED: topsort_m2 /usr/bin/gm2 -fpim -flibs=m2pim,m2cor,m2ios -o topsort_m2 ../topsort.mod /usr/bin/ld: cannot find -lm2pim: No such file or directory /usr/bin/ld: cannot find -lm2cor: No such file or directory /usr/bin/ld: cannot find -lm2iso: No such file or directory collect2: error: ld returned 1 exit status As a temporary workaround, I modified my build flags to include the subdirectories containing links to the shared libraries: /usr/bin/gm2 -L/usr/lib/gcc/x86_64-linux-gnu/13/m2/m2pim/ -L/usr/lib/gcc/x86_64-linux-gnu/13/m2/m2cor/ -L/usr/lib/gcc/x86_64-linux- gnu/13/m2/m2iso/ -fpim -flibs=m2pim,m2cor,m2iso -o topsort_m2 ../topsort.mod The GNU Modula-2 packages installed are: gm2_4:13.2.0-1_amd64 gm2-13_13.2.004_amd64 libgm2-13-dev_13.2.0-4_amd64 libgm2-18_13.2.0-4_amd64 -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages gm2-13 depends on: ii g++-13 13.2.0-4 ii gcc-13-base13.2.0-4 ii libc6 2.37-9 ii libgcc-s1 13.2.0-4 ii libgm2-13-dev 13.2.0-4 ii libgmp10 2:6.3.0+dfsg-2 ii libisl23 0.26-3 ii libmpc31.3.1-1 ii libmpfr6 4.2.1-1 ii libstdc++6 13.2.0-4 ii libzstd1 1.5.5+dfsg2-1 ii zlib1g 1:1.2.13.dfsg-3 gm2-13 recommends no packages. gm2-13 suggests no packages. -- no debconf information
Bug#891489: gcc-8: attribute no_sanitize does not accept multiple options as documented
Package: gcc-8
Version: 8-20180218-1
Severity: normal
Hi,
In
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-no_005fsanitize-function-attribute
gcc 8.0.1 claims to add a no_sanitize attribute which works the same as
the clang one does.
In practice however it doesn't, and it currently will only accept a
single option. The example given above is:
$ cat nosan.c
void __attribute__ ((no_sanitize ("alignment", "object-size")))
f () { /* Do something. */; }
int main(void) { return 0; }
Which results in:
$ gcc-8 nosan.c
nosan.c:3:1: error: wrong number of arguments specified for ‘no_sanitize’
attribute
f () { /* Do something. */; }
^
It would be really nice if that did work as documented, to avoid having
to special case this in user code even more than we already do.
Cheers,
Ron
Bug#841533: You could revert to gcc-5
You can use this to revert to gcc-5, which still works.
Use it as:
# gcc-select
e.g.
# gcc-select 6 5
... will revert to gcc 5 to allow you to compile a kernel.
# gcc-select 5 6
... will revert to gcc-6.
Obviously, you need to be root for this. And while it works fine for
gcc-5 and gcc-6, I have no idea whether it'll work for previous or
future gcc versions. It depends on whether gcc, cc and other executables
are symlinked to gcc-5, cc-6 and so on.
Hope it helps.
.....Ron
--
Ron Murray
PGP Fingerprint: 4D99 70E3 2317 334B 141E 7B63 12F7 E865 B5E2 E761
#! /bin/bash
# Select gcc version
# Assumes "gcc" etc in linked to "gcc-5" etc
BINDIR="/usr/bin"
# Array contining links to be changed
declare LINKS=("cpp" "g++" "gcc" "gcc-ar" "gcc-nm" "gcc-ranlib" \
"gcov" "gcov-tool" "gfortran")
# Make sure it's specified
OLDVER=$1
NEWVER=$2
if [ -z "${OLDVER}" ] || [ -z "${NEWVER}" ]
then
echo "Usage: gcc-select [oldver] [newver]"
echo "Currently:"
ls -l ${BINDIR}/${LINKS[0]}
exit
fi
for LINK in ${LINKS[*]}
do
echo ${LINK}
# Check that old and new destinations exist
TARGET=${BINDIR}/${LINK}
OLDPOINT=${TARGET}-${OLDVER}
NEWPOINT=${TARGET}-${NEWVER}
if [ ! -e ${OLDPOINT} ]
then
echo "Current destination ${OLDPOINT} doesn't exist."
exit
fi
if [ ! -e ${NEWPOINT} ]
then
echo "Intended destination ${NEWPOINT} doesn't exist."
exit
fi
if ! rm -f ${TARGET}
then
echo "Error removing link ${TARGET}."
exit
fi
if ! ln -sf ${NEWPOINT} ${TARGET}
then
echo "Error creating symbolic link ${NEWPOINT} --> ${TARGET}"
exit
fi
done
echo "Done."
signature.asc
Description: OpenPGP digital signature
Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
Helmut wrote: > On Wed, Nov 19, 2014 at 04:41:49PM -0800, Don Armstrong wrote: > > Are people who are doing cross-building like this actually using the > > code which will be in jessie? I (perhaps naïvely) would expect them to > > be primarily using the code in unstable, and maybe at a late stage of > > bring-up rebuilding all of stable. > > Thanks for asking this. Let me give two answers to this question: > > 1) No. The continuous integration happened in sid and people >bootstrapping new architectures tend to use sid plus patches. However >the method of bootstrapping that was known working two weeks before >the freeze no longer works. Whatever method is going to be used now, >it requires changing packages. Since these changes tend to not fall >under the freeze policy, they are practically not mergeable. So in >this answer, jessie is to be understood as a time frame: Keep things >working that worked before until we are allowed to fix things. > > 2) Yes. People repeatedly ask for cross toolchains on stable systems. >This is the very reason why Wookey tried to package them for jessie. >Ultimately, they ended being late, so people will try to build them >on their own and for the popular targets (mostly armhf, armel) this >actually worked. We've been using this for development of embedded systems where building on native hardware (or in an emulator) is ridiculously slow (or even impossible for some devices) compared to cross building from Debian on more powerful hardware. That worked great for all releases up to and including Squeeze. For Wheezy, the late introduction of multi-arch basically broke that and doing this on that release was effectively impossible. The change which was reverted here had made doing that on Jessie possible once again, and made it a relatively trivial matter to build your own cross-toolchain using the packaged gcc source (in the absence of those being able to actually be uploaded as pre-built binaries yet). I'd be kind of sad if that stopped being possible again for the final released version of Jessie, and we had to skip yet another release before being able to do this on Debian again. It may not be the best and final answer, but it has some advantages over the proposed alternative, like being able to work with existing m-a packages without needing to rebuild custom versions of everything, and actually working on Debian today. It's not clear to me what advantage was gained by removing it before the alternative to it is actually viable to use, or what problem it had that made doing that compelling. Unless someone can show me that, I'd definitely prefer to have this functionality restored again for Jessie. It's definitely desirable to have this on a stable system, since the lock-step requirement of m-a makes it rather more painful to keep this all working on an unstable system where packages are changing rapidly (and because stable deps are kind of an important thing too :) Cheers, Ron -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141121144342.go29...@hex.shelbyville.oz
Bug#720363: gcc-4.9: libphobos fails to cross-build
Hi, I ran into pretty much exactly the same thing as the original reporter here, except with gcc 4.9.1-14 and I was building an armel cross-compiler on amd64. In answer to your pending question then: > please find out why the libphobos build is not enabled, > or fails to build. There appears to be (at least) two things broken with libphobos, the first I found was: gcc-4.9-4.9.1/src/libphobos/configure: line 2908: GCC_NO_EXECUTABLES: command not found Which seems to be because it's not searching src/config for m4 macros, or at least didn't the last time it was autoreconfed. I don't know if that's new for 4.9.1, or if the OP also hit that. The patch below should fix that, but I wasn't able to actually test it, since either I'm missing some trick about how you are supposed to autoreconf src/libphobos, or it actually needs some stone-age version of RHEL or something to be able to work. When I tried, some macros complained about strictly needing autoconf 2.64, and when I gave it that others complained about needing at least 2.65 ... So I hand hacked my way past that one, and then promptly ran into a second problem ... which should have been evident from what the original reporter posted, and which they definitely did hit. > dh_movefiles: debian/tmp/usr/lib/arm-linux-gnueabi/libgphobos2.a not found > (supposed to put it in libphobos-4.9-dev) Which isn't because it failed to build, but because it was instead installed in: debian/tmp/usr/arm-linux-gnueabi/lib/libgphobos2.a (note the location of the /lib/ in those two paths ;) Which appears to be a packaging bug, and at that point it was clear that nobody has ever actually built this with m-a cross, so I threw my hands in the air and did what presumably everyone else has done and just nolang'd out all the things I don't actually care about myself :) But if those two get fixed it should be at least one step closer to working for whoever tries it next! Cheers, Ron --- src/libphobos/Makefile.am.orig 2014-09-20 02:26:48.194792033 +0930 +++ src/libphobos/Makefile.am 2014-09-20 02:27:43.702816970 +0930 @@ -25,6 +25,8 @@ # Multilib support. MAKEOVERRIDES= +ACLOCAL_AMFLAGS = -I . -I .. -I ../config + # Work around what appears to be a GNU make bug handling MAKEFLAGS # values defined in terms of make variables, as is the case for CC and # friends when we are called from the top level Makefile. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140919192942.ga32...@hex.shelbyville.oz
Bug#608029: typeinfo for armel is not weak when templates are explicitly instantiated
Actually, according to the C++ standard, 14.7 clause 5 says: - an explicit instantiation definition shall appear at most once in a program So the example I gave is ill-formed, and armel is probably the one making a useful and correct optimisation based on that. C++ also says we aren't required to issue a diagnostic for this error - so strictly speaking I guess neither behaviour is a bug in gcc at all, unless upstream want to minimise the divergence between how code is handled on different arches. Sorry for the noise, if you don't think this is something upstream should or would care to know about, then you're welcome to close it. Ron -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101226082944.gi2...@audi.shelbyville.oz
Bug#608029: typeinfo for armel is not weak when templates are explicitly instantiated
Package: g++-4.4
Version: 4.4.5-10
Severity: normal
Hi,
I ran into this porting some existing code to armel, but a minimal example
follows. Shown here using a cross compiler, but I've confirmed that it can
be reproduced on native armel with both gcc-4.4 from squeeze and gcc-4.5
from experimental (4.5.2-1).
$ cat Makefile
out: b.o c.o
$(CXX) $^ -o d
$ cat a.h
template struct A { T a; virtual ~A() {} };
template struct A;
$ cat b.cpp
#include "a.h"
void use_A() { A b; }
$ cat c.cpp
#include "a.h"
int main() { A c; return 0; }
$ make CXX=arm-linux-gnueabi-g++
arm-linux-gnueabi-g++-c -o b.o b.cpp
arm-linux-gnueabi-g++-c -o c.o c.cpp
arm-linux-gnueabi-g++ b.o c.o -o d
c.o:(.rodata+0x0): multiple definition of `typeinfo for A'
b.o:(.rodata+0x0): first defined here
c.o:(.rodata+0x8): multiple definition of `typeinfo name for A'
b.o:(.rodata+0x8): first defined here
collect2: ld returned 1 exit status
This works fine on amd64 though. The interesting difference seems to be
that amd64 produces:
V _ZTI1AIiE
V _ZTS1AIiE
V _ZTV1AIiE
While armel gives us:
R _ZTI1AIiE
0008 R _ZTS1AIiE
V _ZTV1AIiE
If the template is left to be implicitly instantiated, then armel also
produces weak symbols for the typeinfo (but that causes other trouble
in the original example).
I found some hints of an earlier report upstream here:
http://gcc.gnu.org/ml/gcc-help/2010-02/msg00361.html
http://gcc.gnu.org/ml/gcc-help/2010-03/msg7.html
But that didn't seem to end with any real conclusion as to what the
original problem was, which I think this example does demonstrate now.
Cheers,
Ron
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages g++-4.4 depends on:
ii gcc-4.4 4.4.5-10 The GNU C compiler
ii gcc-4.4-base 4.4.5-10 The GNU Compiler Collection (base
ii libc6 2.11.2-7 Embedded GNU C Library: Shared lib
ii libgmp3c2 2:4.3.2+dfsg-1 Multiprecision arithmetic library
ii libmpfr4 3.0.0-2multiple precision floating-point
ii libstdc++6-4.4-dev4.4.5-10 The GNU Standard C++ Library v3 (d
g++-4.4 recommends no packages.
Versions of packages g++-4.4 suggests:
pn g++-4.4-multilib (no description available)
ii gcc-4.4-doc 4.4.4.nf1-1 documentation for the GNU compiler
pn libstdc++6-4.4-dbg (no description available)
-- no debconf information
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20101226070548.2482.77531.report...@audi.shelbyville.oz
Bug#524059: Hmm...actually, rebooting worked
Wow, I should have known to do that. My apologies for the troubles. I followed the advice in the previous post, and rebooting worked. I have no clue how the RAM got corrupt. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#498744: gcc -m32 seems to ignore -L flag
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. However, I have tried all of the usual
fixes and none of them work. In particular, gcc seems to be ignoring
my -L flag:
[EMAIL PROTECTED]:~]$ dpkg -l gcc
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-
installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name VersionDescription
+++-==-==-
ii gcc4.1.1-15 The GNU C compiler
[EMAIL PROTECTED]:~]$ dpkg -l ia32-libs
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-
installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name VersionDescription
+++-==-==-
ii ia32-libs 1.19 ia32 shared libraries for use on
amd64 and i
[EMAIL PROTECTED]:~]$ cat test.c
#include
main () { printf("%d\n", sizeof(void*)); }
[EMAIL PROTECTED]:~]$ gcc -m32 -L/usr/lib32 test.c
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.so when
searching for -lc
/usr/bin/ld: skipping incompatible /usr/bin/../lib/libc.a when
searching for -lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.so when searching for
-lc
/usr/bin/ld: skipping incompatible /usr/lib/libc.a when searching for -
lc
/usr/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#344501: g++-4.0: spurious warning about explicit conversion operator to same type
Package: g++-4.0
Version: 4.0.2-5
Severity: normal
Hi,
Given the following (stripped down) code as variant.cpp:
#include
using std::cout;
using std::endl;
struct Variant
{
Variant() {}
template< typename T > Variant( T ) {}
Variant( const Variant& ) {}
Variant &operator=( const Variant& ) { return *this; }
template< typename T > operator T() const
{
cout << "operator T() called" << endl;
return T();
}
template< typename T > operator const T&() const
{ static T test_dummy;
cout << "operator T&() called with T = Variant, uh oh" << endl;
return test_dummy;
}
#ifdef WITH_WARNING
operator Variant() const
{
cout << "operator Variant() called" << endl;
return *this;
}
operator const Variant&() const
{
cout << "but operator Variant&() _is_ called" << endl;
return *this;
}
#endif
};
Variant TempMaker( Variant v ) { return v; }
int main()
{
Variant v = TempMaker( 1 );
return 0;
}
The following may be observed:
$ make variant "CPPFLAGS=-Wconversion -DWITH_WARNING"
g++ -Wconversion -DWITH_WARNING variant.cpp -o variant
variant.cpp:39: warning: conversion to the same type will never use a
type conversion operator
variant.cpp:44: warning: conversion to a reference to the same type
will never use a type conversion operator
$ ./variant
but operator Variant&() _is_ called
$ make variant CPPFLAGS=-Wconversion
g++ -Wconversion variant.cpp -o variant
$ ./variant
operator T&() called with T = Variant, uh oh
Indicating that the explicit operators are in fact called, despite
the warning, and are in fact necessary to avoid the compiler attempting
to use the template conversion operator with T = Variant(&) (and doing
bad recursive things in less stripped code) when temporaries are created
for the function call.
The simple answer to me is get rid of the warning, the code operates
intuitively correctly now, but things are rarely simple...
cheers,
Ron
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages g++-4.0 depends on:
ii gcc-4.0 4.0.2-5The GNU C compiler
ii gcc-4.0-base 4.0.2-5The GNU Compiler Collection (base
ii libc6 2.3.5-9GNU C Library: Shared libraries an
ii libstdc++6-4.0-dev4.0.2-5The GNU Standard C++ Library v3 (d
g++-4.0 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#288555: g++-3.3: typeof operator is misparsed in a template function
Package: g++-3.3
Version: 1:3.3.5-5
Severity: normal
Hi,
the following program fails to compile with g++-3.3 like so:
$ g++-3.3 -c -o a.o a.cpp
a.cpp: In function `void C()':
a.cpp:10: error: `__typeof (A)' is not a valid type for a template
constant parameter
a.cpp:10: error: ISO C++ forbids declaration of `b' with no type
const int A = 1;
template< typename T, T t > class B {};
template< typename T >
void C()
{
// This is not ok here.
B< __typeof__( A ), A > b;
}
int main()
{
// But fine here and most other places.
B< __typeof__( A ), A > b;
return 0;
}
From what I understand of that error, it appears to be quite
muddled up about things at that point. g++-3.4 seems to compile
this without warning though, so I guess it is time for me to put
all the rest of my code through its wringer too... :-)
cheers,
Ron
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages g++-3.3 depends on:
ii gcc-3.3 1:3.3.5-5The GNU C compiler
ii gcc-3.3-base1:3.3.5-5The GNU Compiler Collection (base
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries an
ii libstdc++5-3.3-dev 1:3.3.5-5The GNU Standard C++ Library v3 (d
-- no debconf information
Bug#211898: libstdc++5-dev: data_type typedef not recognized for std::map
Package: libstdc++5-dev
Version: 1:3.2.3-8
Severity: normal
The following test code:
#include
typedef std::map MapType;
int main()
{
MapType::key_type foo = 0;
MapType::data_type bar = 0;
return bar;
}
fails with an error at the MapType::data_type line:
map_data_type_bug.cpp: In function `int main()':
map_data_type_bug.cpp:8: error: `data_type' is not a member of type `
std::map, std::allocator
> >'
map_data_type_bug.cpp:8: error: syntax error before `=' token
map_data_type_bug.cpp:10: error: `bar' undeclared (first use this function)
map_data_type_bug.cpp:10: error: (Each undeclared identifier is reported only
once for each function it appears in.)
key_type and value_type are recognized, but data_type is not. This breaks
conformance with the STL standard (and, of course, my code :)).
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux ouroboros 2.4.20 #5 Mon Apr 14 17:15:56 PDT 2003 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages libstdc++5-dev depends on:
ii g++-3.21:3.2.3-8 The GNU C++ compiler
ii gcc-3.2-base 1:3.2.3-8 The GNU Compiler Collection (base
ii libc6-dev 2.3.2-7 GNU C Library: Development Librari
ii libstdc++5 1:3.3.1-0pre0 The GNU Standard C++ Library v3
-- no debconf information
Re: Stupid me ! Was about your cross-compiling packages.
Howdy,
I like the idea of this in principle. In practice though, I think
I'd rather see it start out as more of a best practices guide, drawing
from the lessons learned in the existing packages (and not only Debian
ones), than an attempt at making policy right off the bat.
Before enshining any of this in policy, it should have the acceptance of
upstream compiler folk, and probably of people packaging cross compilers
for other dists and the FHS folk too.
I ideally want to be able to take any piece of software and build it
native and (where applicable) cross without excessive prior debianisation.
To do that we need wide agreement on the toolchain interface.
For that reason (among others) I have bad feelings about the idea of
moving support files into /usr/share anytime soon.
I like the idea of moving as much as possible into the mainstream gcc
release and building all toolchains from a single source, but I think
a realistic approach involves exciting the upstream patch maintainers
to do this. I know it is a goal of the mingw folk to minimise the
amount of code they have outside the main gcc cvs, but I also know
how much additional work the packages would demand if they weren't
simple wrappers around the upstream design decisions. (so browse the
contents of the mingw packages if you want to see the locations its
upstream currently advocate)
If you're going to have c-compiler- as a virtual package, then
you're also going to want {c++,objc,fortran,pascal,java,etc}-compiler-
a mix of which each package might provide.
The section on target runtimes needs to take into account that not all
compilers will produce compatible object files. A binary package may
need to depend on g++- since not all packages supplying
c++-compiler- may work with it.
See bts #165848 for prior rantage on /usr/arch/bin.
I've also added debian-gcc to the cc. If anyone from there would like
to chime in, they probably carry a more current and informed opinion
than mine.
best,
Ron
On Fri, May 23, 2003 at 11:05:14AM +0200, Jeremie Koenig wrote:
> Well, my humble excuses to those of you who got the weird message. Using
> xargs with mutt... I really should go to sleep :(
>
> I just wanted to drop you a note, as maintainers of cross compiling
> packages. I'm preparing packages for a DJGPP (DOS) cross-compiler
> together with Victor (cc'ed above), and i remarked that cross-compilers
> didn't follow any common guidelines in debian. So I drafted something
> i'd like to submit to you.
>
> If you find some time, could you have a quick look ?
> http://sprite.fr.eu.org/cross-packages-mini-policy.txt
>
> Please tell me if you're interested by the initiative, so i won't bother
> any longer those who aren't.
>
> --
> Jeremie Koenig <[EMAIL PROTECTED]>
>
>
