Bug#157416: preprocessor/8524: _Pragma within macros is improperly expanded
Synopsis: _Pragma within macros is improperly expanded Responsible-Changed-From-To: unassigned->neil Responsible-Changed-By: neil Responsible-Changed-When: Sun Nov 10 22:44:07 2002 Responsible-Changed-Why: Mine. State-Changed-From-To: open->analyzed State-Changed-By: neil State-Changed-When: Sun Nov 10 22:44:07 2002 State-Changed-Why: Yah, I'm not entirely surprised; the code in question is not pretty. I'll take another look. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8524
Bug#153965: c/8602: incorrect line numbers in warning messages when using inline functions
Synopsis: incorrect line numbers in warning messages when using inline functions State-Changed-From-To: open->analyzed State-Changed-By: neil State-Changed-When: Sat Nov 16 03:23:59 2002 State-Changed-Why: Confirmed. Change category to C as it clearly has nothing to do with preprocessor. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8602
Bug#157416: preprocessor/8524: _Pragma within macros is improperly expanded
Synopsis: _Pragma within macros is improperly expanded State-Changed-From-To: analyzed->open State-Changed-By: neil State-Changed-When: Sun Nov 17 14:07:28 2002 State-Changed-Why: Patch in progress. Let's nail this for good. Other than a rewrite the only possible fix is a kludge, so let's keep our fingers crossed. (GNATs insists I change state, consider it "analyzed"). http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8524
Bug#157416: preprocessor/8524: _Pragma within macros is improperly expanded
Synopsis: _Pragma within macros is improperly expanded State-Changed-From-To: open->closed State-Changed-By: neil State-Changed-When: Mon Nov 18 12:51:59 2002 State-Changed-Why: Fixed, I hope. Applied in 3.3, will soon apply in 3.2.2. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=8524
get me Rolex or Cartier or Breitling
Get the Finest Rolex Watch Replica ! We only sell premium watches. There's no battery in these replicas just like the real ones since they charge themselves as you move. The second hand moves JUST like the real ones, too. These original watches sell in stores for thousands of dollars. We sell them for much less. - Replicated to the Smallest Detail - 98% Perfectly Accurate Markings - Signature Green Sticker w/ Serial Number on Watch Back - Magnified Quickset Date - Includes all Proper Markings http://www.chooseyourwatch4u.com/ you stereography me transfinite me [2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: bootstrap/2987
Synopsis: gcc 3.0 0526 fails to build on mips State-Changed-From-To: open->closed State-Changed-By: neil State-Changed-When: Wed Jun 6 05:32:48 2001 State-Changed-Why: I believe this has been fixed; we have since had successful builds, e.g. http://gcc.gnu.org/ml/gcc-testresults/2001-06/msg00128.html http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=2987&database=gcc
Re: preprocessor/7558: preprocessor option -MM has change semantic
[EMAIL PROTECTED] wrote:- > >Description: > In gcc 3.1, -MM prints dependencies even to files included with > angle brackets (), if those are found through -I options. > This behaviour is unintuitive and a change from earlier versions. Why are you using <> brackets? Why is #include "foo.h" not good enough? Neil.
Re: preprocessor/7558: preprocessor option -MM has change semantic
Martin, If it's a system header, why are you lying to the compiler? Maybe a real-life example and not "a.h" would help. Neil.
Re: preprocessor/7558: preprocessor option -MM has change semantic
Martin v. Loewis wrote:- > Neil Booth <[EMAIL PROTECTED]> writes: > > > If it's a system header, why are you lying to the compiler? > > I'm not lying, I use You've not told the compiler it's a system header, so it doesn't think it is. Let me see what Zack thinks. Neil.
Bug#157416: _Pragma() from macros - bug
Zack Weinberg wrote:-
> This was reported to the Debian bug-tracking system:
>
> $ cat foo.c
> _Pragma("foo"); int y;
> #define FOO _Pragma("foo"); int x;
> FOO
> [EMAIL PROTECTED]:~$ cpp-3.2 foo.c
> # 1 "foo.c"
> # 1 ""
> # 1 ""
> # 1 "foo.c"
>
> # 1 "foo.c"
> #pragma foo
> # 1 "foo.c"
> ; int y;
>
>
> # 3 "foo.c"
> #pragma ; int x;foo
>
> > The first line is expanded correctly; the third is not (rendering
> > _Pragma almost completely useless).
>
> Do you have time to look into this, Neil?
I'll try to have a look this weekend.
Neil.
Bug#157416: _Pragma() from macros - bug
Zack Weinberg wrote:-
> This was reported to the Debian bug-tracking system:
>
> $ cat foo.c
> _Pragma("foo"); int y;
> #define FOO _Pragma("foo"); int x;
> FOO
> [EMAIL PROTECTED]:~$ cpp-3.2 foo.c
> # 1 "foo.c"
> # 1 ""
> # 1 ""
> # 1 "foo.c"
>
> # 1 "foo.c"
> #pragma foo
> # 1 "foo.c"
> ; int y;
>
>
> # 3 "foo.c"
> #pragma ; int x;foo
>
> > The first line is expanded correctly; the third is not (rendering
> > _Pragma almost completely useless).
>
> Do you have time to look into this, Neil?
Fixed with a nasty kludge thus.
We really should be leaving _Pragma as-is in preprocessed output IMO;
(but processing it for pragmas handled by CPP itself) then this whole
issue goes away, and so does the hoops I jump through to retain
correct token line numbering. That's for 3.4.
Bootstrapped and regtested; I'm going to put this in.
Neil.
* cpphash.h (FIRST, LAST, CUR, RLIMIT): Fix definitions.
* cpplib.c (destringize_and_run): Kludge around getting
tokens from in-progress macros.
(_cpp_do__Pragma): Simplify.
testsuite:
* gcc.dg/cpp/_Pragma4.c: New test.
Index: cpphash.h
===
RCS file: /cvs/gcc/gcc/gcc/cpphash.h,v
retrieving revision 1.170
diff -u -p -r1.170 cpphash.h
--- cpphash.h 12 Aug 2002 22:44:29 - 1.170
+++ cpphash.h 3 Sep 2002 21:51:47 -
@@ -166,10 +166,10 @@ struct tokenrun
};
/* Accessor macros for struct cpp_context. */
-#define FIRST(c) (c->u.iso.first)
-#define LAST(c) (c->u.iso.last)
-#define CUR(c) (c->u.trad.cur)
-#define RLIMIT(c) (c->u.trad.rlimit)
+#define FIRST(c) ((c)->u.iso.first)
+#define LAST(c) ((c)->u.iso.last)
+#define CUR(c) ((c)->u.trad.cur)
+#define RLIMIT(c) ((c)->u.trad.rlimit)
typedef struct cpp_context cpp_context;
struct cpp_context
Index: cpplib.c
===
RCS file: /cvs/gcc/gcc/gcc/cpplib.c,v
retrieving revision 1.321
diff -u -p -r1.321 cpplib.c
--- cpplib.c14 Aug 2002 20:17:54 - 1.321
+++ cpplib.c3 Sep 2002 21:51:47 -
@@ -1277,6 +1277,9 @@ destringize_and_run (pfile, in)
{
const unsigned char *src, *limit;
char *dest, *result;
+ cpp_context saved_context;
+ cpp_context *saved_cur_context;
+ unsigned int saved_line;
dest = result = alloca (in->len + 1);
for (src = in->text, limit = src + in->len; src < limit;)
@@ -1288,7 +1291,40 @@ destringize_and_run (pfile, in)
}
*dest = '\0';
+ /* FIXME. All this saving is a horrible kludge to handle the case
+ when we're in a macro expansion.
+
+ A better strategy it to not convert _Pragma to #pragma if doing
+ preprocessed output, but to just pass it through as-is, unless it
+ is a CPP pragma in which case is should be processed normally.
+ When compiling the preprocessed output the _Pragma should be
+ handled. This will be become necessary when we move to
+ line-at-a-time lexing since we will be macro-expanding the line
+ before outputting / compiling it. */
+ saved_line = pfile->line;
+ saved_context = pfile->base_context;
+ saved_cur_context = pfile->context;
+ pfile->context = &pfile->base_context;
run_directive (pfile, T_PRAGMA, result, dest - result);
+ pfile->context = saved_cur_context;
+ pfile->base_context = saved_context;
+ pfile->line = saved_line;
+
+ /* See above comment. For the moment, we'd like
+
+ token1 _Pragma ("foo") token2
+
+ to be output as
+
+ token1
+ # 7 "file.c"
+ #pragma foo
+ # 7 "file.c"
+ token2
+
+ Getting the line markers is a little tricky. */
+ if (pfile->cb.line_change)
+(*pfile->cb.line_change) (pfile, pfile->cur_token, false);
}
/* Handle the _Pragma operator. */
@@ -1298,26 +1334,11 @@ _cpp_do__Pragma (pfile)
{
const cpp_token *string = get__Pragma_string (pfile);
- if (!string)
+ if (string)
+destringize_and_run (pfile, &string->val.str);
+ else
cpp_error (pfile, DL_ERROR,
"_Pragma takes a parenthesized string literal");
- else
-{
- /* Ideally, we'd like
- token1 _Pragma ("foo") token2
-to be output as
- token1
- # 7 "file.c"
- #pragma foo
- # 7 "file.c"
- token2
-Getting these correct line markers is a little tricky. */
-
- unsigned int orig_line = pfile->line;
- destringize_and_run (pfile, &string->v
Bug#157416: _Pragma() from macros - bug
Steve Ellcey wrote:- > > I am confused by the new test gcc.dg/cpp/_Pragma4.c that was added by > this patch and wonder if I am missing something or if there is a typo in > the test. > > I believe the test is searching for the string '#pragma bat' (bat with a > t) to see if the tests succeeded, but how would that appear in the > output? Shouldn't it be searching for '#pragma bar' (bar with an r)? > Or am I just really confused? The test is currently failing for me. Indeed, I wonder how I hadn't noticed. I've fixed the typo. I've a nasty feeling the fix I gave doesn't work in all cases anyway; a proper fix might have to wait for 3.4. Neil.
Re: preprocessor/8524: _Pragma within macros is improperly expanded
I think this fixes it for good. I'm applying this to 3.3, and 3.2.2
when it arrives.
Neil.
PR preprocessor/8524
* cpplib.c (run_directive): Remove previous kludge to _Pragma.
Add a new one in its place, which hopefully works.
(skip_rest_of_line): Change test for bottom-of-context-stack.
testsuite:
* gcc.dg/cpp/_Pragma5.c: New test.
Index: cpplib.c
===
RCS file: /cvs/gcc/gcc/gcc/cpplib.c,v
retrieving revision 1.324
diff -u -p -r1.324 cpplib.c
--- cpplib.c22 Sep 2002 02:03:17 - 1.324
+++ cpplib.c17 Nov 2002 22:11:21 -
@@ -207,7 +207,7 @@ skip_rest_of_line (pfile)
cpp_reader *pfile;
{
/* Discard all stacked contexts. */
- while (pfile->context != &pfile->base_context)
+ while (pfile->context->prev)
_cpp_pop_context (pfile);
/* Sweep up all tokens remaining on the line. */
@@ -1277,9 +1277,6 @@ destringize_and_run (pfile, in)
{
const unsigned char *src, *limit;
char *dest, *result;
- cpp_context saved_context;
- cpp_context *saved_cur_context;
- unsigned int saved_line;
dest = result = alloca (in->len + 1);
for (src = in->text, limit = src + in->len; src < limit;)
@@ -1291,24 +1288,29 @@ destringize_and_run (pfile, in)
}
*dest = '\0';
- /* FIXME. All this saving is a horrible kludge to handle the case
- when we're in a macro expansion.
-
- A better strategy it to not convert _Pragma to #pragma if doing
- preprocessed output, but to just pass it through as-is, unless it
- is a CPP pragma in which case is should be processed normally.
- When compiling the preprocessed output the _Pragma should be
- handled. This will be become necessary when we move to
- line-at-a-time lexing since we will be macro-expanding the line
- before outputting / compiling it. */
- saved_line = pfile->line;
- saved_context = pfile->base_context;
- saved_cur_context = pfile->context;
- pfile->context = &pfile->base_context;
- run_directive (pfile, T_PRAGMA, result, dest - result);
- pfile->context = saved_cur_context;
- pfile->base_context = saved_context;
- pfile->line = saved_line;
+ /* Ugh; an awful kludge. We are really not set up to be lexing
+ tokens when in the middle of a macro expansion. Use a new
+ context to force cpp_get_token to lex, and so skip_rest_of_line
+ doesn't go beyond the end of the text. Also, remember the
+ current lexing position so we can return to it later.
+
+ Something like line-at-a-time lexing should remove the need for
+ this. */
+ {
+cpp_context *saved_context = pfile->context;
+cpp_token *saved_cur_token = pfile->cur_token;
+tokenrun *saved_cur_run = pfile->cur_run;
+
+pfile->context = xnew (cpp_context);
+pfile->context->macro = 0;
+pfile->context->prev = 0;
+run_directive (pfile, T_PRAGMA, result, dest - result);
+free (pfile->context);
+pfile->context = saved_context;
+pfile->cur_token = saved_cur_token;
+pfile->cur_run = saved_cur_run;
+pfile->line--;
+ }
/* See above comment. For the moment, we'd like
Re: preprocessor/8524: _Pragma within macros is improperly expanded
Neil Booth wrote:-
> I think this fixes it for good. I'm applying this to 3.3, and 3.2.2
> when it arrives.
>
> Neil.
>
> PR preprocessor/8524
> * cpplib.c (run_directive): Remove previous kludge to _Pragma.
> Add a new one in its place, which hopefully works.
> (skip_rest_of_line): Change test for bottom-of-context-stack.
> testsuite:
> * gcc.dg/cpp/_Pragma5.c: New test.
Oops, the test got lost waiting for CVS.
Neil.
Index: testsuite/gcc.dg/cpp/_Pragma5.c
===
RCS file: testsuite/gcc.dg/cpp/_Pragma5.c
diff -N testsuite/gcc.dg/cpp/_Pragma5.c
--- /dev/null 1 Jan 1970 00:00:00 -
+++ testsuite/gcc.dg/cpp/_Pragma5.c 18 Nov 2002 20:40:43 -
@@ -0,0 +1,14 @@
+/* { dg-do preprocess } */
+
+/* Based on Debian GNATS PR 8524. 17 Nov 2002. */
+
+#define ALPHA(A) alpha_ ## A
+#define BETA(B) beta_ ## B
+#define GAMMA(C) _Pragma("moose") ALPHA(C) BETA(C)
+GAMMA(baz);
+
+/*
+ { dg-final { if ![file exists _Pragma5.i] { return } } }
+ { dg-final { if { [grep _Pragma5.i "alpha_baz beta_baz;"] != "" } { return
} } }
+ { dg-final { fail "_Pragma5.c: _Pragma in macro" } }
+*/
Re: c/9762: Address of 'char' is incorrect.
[EMAIL PROTECTED] wrote:-
> In the example below, '&a' is the address of a local copy of 'a' not of
> 'a'.
> if the type of 'a' is changed to int, it works as expected.
Works as who expected? Where is the bug? Please quote which part of
the C standard is violated. You got an address, why are you unhappy?
Neil.
> #define TA char
> #define TB int
> #define TC int
>
> void foobar(TA a, TB b, TC c);
>
> int main()
> {
> foobar(1,2,3);
> return 0;
> }
>
> void foobar(TA a, TB b, TC c)
> {
> printf("a == %i claims %x\n", a, &a);
> printf("a == %i really %x\n", (&b)[-1], (&b)-1);
> printf("b == %i %x\n", b, &b);
> printf("c == %i %x\n", c, &c);
> }
Bug#447381: gcc-4.2: please support the -nodocs build option
Package: gcc-4.2 Version: 4.2.2-3 Severity: wishlist gcc has a complex debian build layout and it isn't straightforward to disable the generation of the various -doc packages when preparing test builds or (in my case) cross builds. It would save a lot of build time and upload time if gcc could support the -nodocs option to prevent the creation of all -doc packages built from the gcc source. Each method that I try to disable the various -doc packages fails to remove them all so it would be really useful if this could be supported within the package. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.22-2-amd64 (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages gcc-4.2 depends on: ii binutils 2.18-1 The GNU assembler, linker and bina ii cpp-4.2 4.2.2-3The GNU C preprocessor ii gcc-4.2-base 4.2.2-3The GNU Compiler Collection (base ii libc6 2.6.1-6GNU C Library: Shared libraries ii libgcc1 1:4.2.2-3 GCC support library ii libgomp1 4.2.2-3GCC OpenMP (GOMP) support library Versions of packages gcc-4.2 recommends: ii libc6-dev 2.6.1-6GNU C Library: Development Librari -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#453267: tested patch
Raphael Hertzog wrote: > On Wed, 05 Dec 2007, Neil Williams wrote: >> My first patch did exactly that - and failed on building a cross >> compiler. gcc needs dpkg-shlibdeps to take notice of $ARCH in the >> preparation of libgcc1-$arch-cross and other libraries used in the >> complete toolchain. It needs (and sets) DEB_TARGET_GNU_TYPE != >> DEB_BUILD_GNU_TYPE at other stages of the build. > > If that's the case, I'd like to know if this is deliberate and really > required... can't the gcc package be consistent and always have both > DEB_TARGET_GNU_TYPE and DEB_BUILD_GNU_TYPE properly set ? Even if gcc changes that behaviour in 4.2 (or 4.3), lots of people still need to be able to build cross compilers from older versions of gcc, especially 4.1 and some even need 3.3 or 3.4. Emdebian still hosts 4.1 and 3.4 toolchains: http://www.emdebian.org/toolchains/search.php?package=gcc-3.4-arm-linux-gnu It's not sensible to say that these cannot be built in the future without writing a whole new diversion for dpkg-shlibdeps. Emdebian and lots of other people doing cross building need backwards compatibility here. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: OpenPGP digital signature
Re: Bug#453267: tested patch
Guillem Jover wrote: > Hi, > > [ I don't have a real opinion yet on the initial patch and this > changes proposed, will try to get to this on Sunday. ] OK, thanks, Guillem. I'd like to get this resolved asap. > On Sat, 2007-12-08 at 19:01:14 +, Neil Williams wrote: >> Raphael Hertzog wrote: >>> On Wed, 05 Dec 2007, Neil Williams wrote: >>>> My first patch did exactly that - and failed on building a cross >>>> compiler. gcc needs dpkg-shlibdeps to take notice of $ARCH in the >>>> preparation of libgcc1-$arch-cross and other libraries used in the >>>> complete toolchain. It needs (and sets) DEB_TARGET_GNU_TYPE != >>>> DEB_BUILD_GNU_TYPE at other stages of the build. >>> If that's the case, I'd like to know if this is deliberate and really >>> required... can't the gcc package be consistent and always have both >>> DEB_TARGET_GNU_TYPE and DEB_BUILD_GNU_TYPE properly set ? > >> Even if gcc changes that behaviour in 4.2 (or 4.3), lots of people still >> need to be able to build cross compilers from older versions of gcc, >> especially 4.1 and some even need 3.3 or 3.4. > > Why can't 4.1 and 3.4 be "fixed" (if that's really needed) as well? > 3.3 might be a problem, but even then you have to build them locally > to support cross-compiling, why can't they be patched locally as well? Local patches are *hell* to maintain - that is why I need to remove the dpkg-cross diversions in the first place. We had local patches for years, we've got passed that stage (thankfully) and desperately need usable cross building support *within* Debian and stop this crazy "patch upon patch upon diversion" approach. Emdebian cannot build, patch or test every permutation of toolchain that people need so this isn't about "us" patching locally, it is about lowering the barrier to cross building on Debian by not forcing every user to patch locally. This is why we are at the current impasse - too many permutations. Why propose changing every version of gcc (a process that could take extreme amounts of time to test, implement and get into testing) and then make it impossible to build cross compilers in Etch? Are we looking at backports as well?? Who is going to do all that work? (Not me, before anyone asks.) This is a problem within dpkg, not actually within gcc. It makes far more sense to change one line in one script than to change every version of gcc. dpkg-shlibdeps is (and has always been) broken with regard to building cross compilers or cross built packages. Various solutions have been created due to this long, long breakage and things are working nicely, all the way back to gcc-3.3 and Etch (possibly earlier). Now that we finally have a chance to fix dpkg-shlibdeps, why must all the previous work be undone? For the sake of one environment variable? This bug is about *removing* the dpkg-cross diversions, not *rewriting* them - changing every gcc package is simply not workable IMHO and the only real alternative to dpkg-shlibdeps supporting $ARCH is for me to write a new diversion of dpkg-shlibdeps that *does* check the value of $ARCH and forces the value of LD_LIBRARY_PATH when building a cross compiler. That would just be a hack so please, can we just check $ARCH in dpkg-shlibdeps? -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: OpenPGP digital signature
Re: Bug#453267: tested patch
Raphael Hertzog wrote:
> On Sun, 09 Dec 2007, Neil Williams wrote:
>> Emdebian cannot build, patch or test every permutation of toolchain that
>> people need so this isn't about "us" patching locally, it is about
>> lowering the barrier to cross building on Debian by not forcing every
>> user to patch locally. This is why we are at the current impasse - too
>> many permutations.
>
> Emdebian provides ready to use cross compiler. You can also provides
> ready-to-use source packages for building other cross-compilers that are
> not yet provided.
? You make it sound as trivial as providing a web page.
Emdebian provides a small selection of binary toolchains containing
selected cross compilers. Extending that range is a truly massive
undertaking that nobody has the time to do. There are no usable
toolchain-source packages anymore - unmaintainable - we can provide
simple scripts that can assist in building a variant toolchain but we do
not provide ready-to-use source packages for building cross compilers.
The major reason why this is so much work is because the necessary
changes have not been incorporated into dpkg and we end up having to
patch a patch of a diversion of a patch.
Emdebian has quite a good relationship with the gcc maintainers and our
patches are generally welcome but that does not diminish the amount of
time involved in making a tested patch in the first place. Emdebian only
has enough developer time to derive patches for the latest versions of
gcc and even then it can be difficult to keep up with gcc releases. We
look forward to the stability of the pre-Lenny freeze because we know
that we can catch up and get a stable set of toolchains for unstable and
testing, all thoroughly tested and fixed. Then as soon as Lenny comes
out, we'll be swamped by gcc changes again. (We, in this case, equals
Hector Oron, myself and Wookey - gcc has a much larger team just for
itself.)
>> Why propose changing every version of gcc (a process that could take
>> extreme amounts of time to test, implement and get into testing) and
>> then make it impossible to build cross compilers in Etch? Are we looking
>> at backports as well?? Who is going to do all that work? (Not me, before
>> anyone asks.)
>
> ARCH is a very generic environment variable that might be set for some
> other reasons (I use it for example in debian-cd) and I don't like to
> change the behaviour of dpkg-shlibdeps just because it's set. IMO,
> there should be a single check to activate cross-building support
cross building != building a cross compiler, as I've said many times.
A single check for cross building is already in place -
DEB_BUILD_GNU_TYPE != DEB_HOST_GNU_TYPE
I created a patch for that in gcc for reverse cross support, it is
included in gcc-4.2.
A mass bug filing is already under way to implement this single check
for cross building support across Debian. The patch to dpkg-shlibdeps
contains a part of that support.
Cross building gcc is NOT the problem. gcc now cross builds just like
any other package in Debian. If reverse cross support in Debian goes
wrong, I'll fix it. I've no problem with that.
Building a cross compiler is a completely separate task and one that has
only become a problem *after* changes in dpkg made the dpkg-cross
diversions impractical.
> and gcc's crossbuild should provide the right variables.
It does, thanks to the reverse cross support in gcc-4.2. Thankfully, we
don't need reverse cross support in 4.1 or earlier. (Well, it would be
nice if it could happen but then nobody has the time to do it so ...)
> I'm ok with a
> supplementary specific check for building of a cross-compiler, but not
> with a generic check like testing the ARCH environment variable.
OK, I have a solution for that - replace $ARCH with $GCC_TARGET.
I've tested with this change to the patch for scripts/Dpkg/Shlibs.pm
# GCC_TARGET for cross compiler builds
my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
($ENV{GCC_TARGET});
...
I went for ARCH before because, in the context of building a cross
compiler, ARCH is only set at certain times. GCC_TARGET is set at the
beginning and is present throughout the build. This means that the
patched dpkg-shlibdeps behaves much more like the original diversion
from dpkg-cross - it effectively extends the list of directories
searched by dpkg-shlibdeps to include the ${crossprefix} ones for every
call throughout the entire build. It may slow things down a little bit
but building a cross compiler isn't exactly quick anyway. It is far more
important that the build completes than shaving a few more seconds off
the build time.
> Furthermore, all the cross-building support in gcc has been contributed
> by various Emdebian people (according to doko), so it looks like Emdebian
> is also able to f
Re: Bug#453267: tested patch
Raphael Hertzog wrote:
> On Sun, 09 Dec 2007, Neil Williams wrote:
>>> I'm ok with a
>>> supplementary specific check for building of a cross-compiler, but not
>>> with a generic check like testing the ARCH environment variable.
>> OK, I have a solution for that - replace $ARCH with $GCC_TARGET.
>>
>> I've tested with this change to the patch for scripts/Dpkg/Shlibs.pm
>>
>> # GCC_TARGET for cross compiler builds
>> my $crossprefix = Dpkg::Arch::debarch_to_gnutriplet($ENV{GCC_TARGET}) if
>> ($ENV{GCC_TARGET});
>> ...
>>
>> I went for ARCH before because, in the context of building a cross
>> compiler, ARCH is only set at certain times. GCC_TARGET is set at the
>> beginning and is present throughout the build.
>
> If I understand you correctly, we can check for GCC_TARGET only and we
> don't need to check DEB_TARGET_GNU_TYPE != DEB_BUILD_GNU_TYPE.
What's the obsession with cutting components out of the patch?? I'm
confused.
dpkg-shlibdeps should at least *support* the "right" way of doing
things, even if the packages currently do not use that. At least it
supports a migration route away from GCC_TARGET for future releases of
gcc. GCC_TARGET is a hack, yes, but we need it around for older
compilers that simply aren't going to get fixed. It would be nice to
provide a migration path to do it TheRightWay(TM) eventually because
that only means changing the latest version of gcc (probably 4.3) and we
can do that in the Lenny freeze when everything else gets easier too. I
don't want to have to go through all this again. GCC_TARGET is likely to
be around until gcc-4.3 gets into oldstable but that's a small price to
pay, IMHO. (It's been around for as long as dpkg-cross which is a decade
so a bit longer isn't going to hurt.)
> Is that correct and does that work ?
I don't believe it is correct but it happens to work - for now.
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
signature.asc
Description: OpenPGP digital signature
Bug#458745: arm-only miscompilation of alloca code
On Thu, 2008-01-03 at 17:44 -0500, Camm Maguire wrote: > Greetings! > > Martin Michlmayr <[EMAIL PROTECTED]> writes: > > > * Camm Maguire <[EMAIL PROTECTED]> [2008-01-02 16:55]: > > > Is EABI the old arm, or the new? Couldn't this make a difference? > > > > I can reproduce the problem with the old ABI (i.e. the current port in > > Debian). I'll open a bug report with GCC. > > Thank you! > > Are we going to have two arm ports, or is the old one going away for > lenny? > There are a lot of devices that need support from the existing Debian arm port as well as newer devices that need the new ABI. There is a possible method for combining the two but both will be needed - and probably for some time after Lenny. Contact debian-arm for more info. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ signature.asc Description: This is a digitally signed message part
Bug#485878: g++-3.4 no longer in testing
Package: g++-3.4 Version: 3.4.6-6 Severity: important g++-3.4 has recently disappeared from testing (although gcc-3.4 is still there). *Please don't do this!* I rely on my Debian testing system for hosting application development that needs to work on all kinds of other platforms, many of which do not run gcc-4 yet. Although I do the initial work in the latest g++-4, I also want to be able to build with every flavour of g++-3, and even with g++-2.95 if possible. I will eventually build on the target platform, of course, but it's great to be able to check for compiler and library compatibility on Linux first, typically using a tinderbox arrangement. I could of course build my own g++ from source, or add the etch repository, but this doesn't seem like the right way to solve the problem. I've noticed the same problem with other packages (eg nVidia drivers) where older versions of packages are taken out of sid before they are able to go into testing (eg because they depend on an xorg version that isn't in testing yet). As a result, there was NO usable nvidia package in testing for a long time (and may be still: I don't know, because I switched to ATI hardware in frustration). Sometimes it feels like testing is the poor relation in the Debian world, and so it's not so surprising that many people have "defected" to Ubuntu. Debian testing works well for someone like myself, who wants a reasonably stable application development platform (ie not sid) but needs access to relatively up-to-date libraries (eg GTK). Sorry for the rant, but hopefully you now see where I am coming from. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (900, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#485878: g++-3.4 no longer in testing
On 6/11/08 6:27 PM, Matthias Klose wrote: IMO our primary focus is the distribution, which doesn't require g++-3.4 for building packages; The provision of packages is so that people who need the software can use it. For example, the reason Debian contains apache2 is so that people can run a web server. Surely the reason g++ is in the distro is so that people who need to do C++ development have a compiler available to them. To say that g++ is only there for the benefit of the system itself seems unreasonable. Would you say the same of fortran, ada, pascal or haskell compilers? We cannot provide you with a repository of old compiler versions. I guess there are limits, but would it really cost you much at all to keep the g++-3 series in the distro for a while longer? Also, it doesn't seem reasonable to throw out g++3.4 when gcc-3.4 is still there. I guess your answer is that there are still packages that need gcc-3.4 and none that need g++-3.4, but I would have thought it made sense to keep the two together. Sometimes it feels like testing is the poor relation in the Debian world, and so it's not so surprising that many people have "defected" to Ubuntu. Debian testing works well for someone like myself, who wants a reasonably stable application development platform (ie not sid) but needs access to relatively up-to-date libraries (eg GTK). I don't see the relation to Ubuntu; these changes will be merged into the current Ubuntu development release with the next merge. There's no special handling unless the MOTU developers decide on it. FYI, g++-3.3 and -3.4 are both in Intrepid, and also in Hardy which is roughly equivalent to where lenny is at right now. I guess this is not the place to have a philosophical debate, but the point I am making is that Debian testing is often broken for practical purposes, and the developers don't really seem to care. The Debian developers put their effort into sid or unstable, and don't seem to care much about testing except as a holding place on the way to stable. However, for a great many desktop users, stable is too old and sid is too new. If testing was looked after properly, I think it would suit a lot of people very well. However, for a system that's actually usable people seem to be much better off with Ubuntu. I really want to stay with Debian, but I'm not sure how much longer I'm going to have the patience for it. Taking the g++-3 series out of testing seems to me to be another example of a lack of interest in the practical usefulness of the testing distro. If testing is to serve its purpose, which is to give packages more extensive testing, it needs to be used by a good number of people. However, people are going to use it if it doesn't serve any practical needs. My comments extend to the whole distro, not just g++. I am thinking of other packages like MonoDevelop, which was completely absent from testing for a long time, although it was right there in Ubuntu. When I asked about it, the maintainer just talked about backporting it into stable, even though I'd already explained that stable wasn't appropriate for me. Your statement about "primary focus" seems to suggest that the needs of people who actually want to use the software on the system aren't as important as the needs of the people who build it. If the majority of Debian developers think that way, Debian is doomed as a distro that ordinary people want to use. Again, I'm sorry to be so off-topic. I'm mostly trying to justify my request for g++-3.4, although if there is a place where I could legitimately discuss my concerns about Debian testing in general, I'd be glad if you could point me to it. --Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#518754: gcc-snapshot: gcc-..-base postinst needs additional error prevention
Package: gcc-snapshot Version: 20090224-1 Severity: normal This issue affects Emdebian Grip in gcc-4.3 but I'm filing it here because Grip has a workaround that is OK for 4.3 and I'm trying to fix the problem before 4.4 arrives. Please let me know if I did that wrong. The -base postinst script does check if a copyright file already exists but then does not check that .copyright also exists. Emdebian Grip has specialised handling of ./usr/share/doc/ to remove documentation and compress all copyright files to save space. Therefore, the postinst fails because ..copyright does not exist, ./copyright.gz does instead. (changelog.Debian.gz is also removed, along with everything else in ./usr/share/doc/$package/). Emdebian currently has an adapted Policy for such changes with a hope to include suitable exceptions at some point in the future. Emdebian Grip does not recompile packages, it is binary-compatible with Debian so that users can choose to install the equivalent Debian package if appropriate, so the underlying functionality needs to be retained, even if the Grip package lacks the data files. (Cross-building is used for Emdebian Crush, a smaller variant that is not binary-compatible with Debian or Grip.) It would be much appreciated if the postinst could check for .copyright and do nothing if it does not exist. Something like: #! /bin/sh -e case "$1" in configure) # see #355439, packaging error in 4.0.2-9* docdir=/usr/share/doc/g...@bv@-base if [ ! -f $docdir/copyright ]; then + if [ -f $docdir/.copyright ]; then ln $docdir/.copyright $docdir/copyright + fi fi if [ ! -f $docdir/changelog.Debian.gz ]; then + if [ -f $docdir/.changelog.Debian.gz ]; then ln $docdir/.changelog.Debian.gz $docdir/changelog.Debian.gz + fi fi esac ? -- System Information: Debian Release: squeeze/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 2.6.26-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
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
> > toolchain, but the current layout we are using by dpkg-cross installs
> > relevant bits under:
> > /{include,bin,lib,lib64}
> > Mainstream code expects a different layout more LHS compliant,
> > /{usr/include,bin,lib,lib64}
dpkg-cross currently does:
/usr/
`-- $arch-linux-gnu/
|-- include/
| `-- foo.h
`-- lib/
`-- libfoo.so
$ ls /usr/arm-linux-gnu/
bin include lib
Very flat but quite simple.
I thought mulitarch wanted:
/usr/
|-- bin/
| `-- $arch-linux-gnu/
|-- include/
| `-- $arch-linux-gnu/
| `-- foo.h
|-- lib64/
| `-- $arch-linux-gnu/
`-- lib/
`-- $arch-linux-gnu/
`-- libfoo.so
?
The problem, as I see it, with /usr/include/$arch-linux-gnu/foo.h is
that it makes it impossible to export one entire tree of all
cross-build stuff. i.e. make /usr/$arch-linux-gnu/ available and
everything is in a single place. Instead, three paths need to be
exported.
So which layout do we need for LHS?
/usr/
`-- $arch-linux-gnu/
|-- bin/
|-- lib64/
!-- lib/
|-- usr/
`-- |-- bin/
|-- include/
| `-- foo.h
`-- lib/
`-- libfoo.so
$ ls /usr/arm-linux-gnu/
bin lib64 lib usr
$ ls /usr/arm-linux-gnu/usr
bin include lib
(with or without a symlink of /usr/arm-linux-gnu/usr/lib64
to /usr/arm-linux-gnu/usr/lib) ?
i.e. a complete hierarchy beneath /usr/arm-linux-gnu/ with files that
are normally in /bin/ in /usr/$arch-linux-gnu/bin and files that are
normally in /usr/bin/ in /usr/$arch-linux-gnu/usr/bin, similarly for
lib.
> >Is there any information arround, maybe LHS, on how to setup
> > layout?
> >
> >Nowadays we are using non multiarch structure as:
> >
> > usr/$arch-linux-gnu
> > |-- bin
> > |-- include
> > |-- lib
> > `-- lib64
> >
> >But what it should look like in future? /usr/include/$arch-linux-gnu?
> > Would it be reasonable to be using a new layout like:
> >
> > usr/include/$arch-linux-gnu
>
> That is already standard on i386/amd64 at least. Many /usr/include/*
> files just include the right usr/include/$arch-linux-gnu file
> depending on wether __i386__ or __x86_64__ is set. gcc also looks into
> those dirs on its own. So yes, do use those.
Is that /usr/include/$arch-linux-gnu/usr/include/foo.h ?
> > |-- bin
>
> All binaries are assumed to do the same thing no matter what
> architecture they are compiled for. As such there is no need to have
> the same binary compiled for different archs at the same time. Also
> any change here would play havock with shebang lines.
binutils-multiarch puts stuff in /usr/$arch-linux-gnu/bin/
$ ls /usr/arm-linux-gnu/bin/
ar as ld nm objcopy objdump ranlib strip
> > I am missing some papers on multiarch, are there any kind of
> > information out there.
>
> You are missing the actual multiarch or cross-compile library dirs:
>
> /usr/$arch-linux-gnu/lib (cross-compile)
> /usr/lib/$arch-linux-gnu (multiarch)
>
> I still haven't heart a good reason why multiarch can't use the
> cross-compile dirs as the libraries for each are ment to be
> interchangable (and in fact dpkg-cross demonstrates that already).
Hmm, so dpkg-cross would need to change the path to include/ for
headers but not change the path for libraries?
We'd have:
/usr/arm-linux-gnu/lib/libfoo.so
/usr/include/arm-linux-gnu/include/foo.h
or
/usr/arm-linux-gnu/usr/lib/libfoo.so
/usr/include/arm-linux-gnu/usr/include/foo.h
?
I thought the question was whether we would have:
/usr/lib/arm-linux-gnu/lib/libfoo.so
or
/usr/lib/arm-linux-gnu/usr/lib/libfoo.so
or
/usr/arm-linux-gnu/usr/lib/libfoo.so
or the current
/usr/arm-linux-gnu/lib/libfoo.so
as a conversion of /usr/lib/libfoo.so
--
Neil Williams
=
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
pgpmAQytPasu5.pgp
Description: PGP signature
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
rsion of /usr/lib/libfoo.so > > The question is > > /arm-linux-gnu/lib/libfoo.so l> /usr/arm-linux-gnu/[usr/]lib/libbla.so > /usr/arm-linux-gnu/[usr/]include/foo.h > > or > > /lib/arm-linux-gnu/libfoo.so > /usr/lib/arm-linux-gnu/libbla.so > /usr/include/arm-linux-gnu/foo.h > > It has always been a question of where to put the tripplet, not > whether or not to have an extra subdir below that. Although I'm > against the subdirs. No need to duplicate that this is "usr". I'd agree - [usr] below $arch-linux-gnu appears redundant to me. The only difference between /lib and /usr/lib/ relates to the libraries required to boot before /usr is mounted. That reasoning doesn't apply to toolchain issues. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpm553xyH46c.pgp Description: PGP signature
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
On Thu, 12 Mar 2009 19:39:11 +0100 Simon Richter wrote: > I think treating cross-building as largely orthogonal to supporting > multiple runtime ABIs on the same system isn't the worst of ideas Maybe not, but it isn't a sustainable idea. >, 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. >, 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 sufficient reason to not move /usr/ to /usr/lib/ and /usr/include/ if it means getting such support into the core Debian packaging tools. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpxvRUFuxrcc.pgp Description: PGP signature
Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain
dle the "current" layout than to patch all the software that assumes > that software is generally installed into "include" and "lib" dirs under a > common prefix (such as most GNU software that uses the autoconf macros to > find installed software). > >Simon That can't work either. If the core Debian packaging tools are going to change in our favour at all, they are going to change to support multiarch - that much has been made clear repeatedly. If cross-building doesn't get up to speed then the packaging tools could change in a way that breaks all cross-builds, not just the harder corner cases. Multiarch isn't perfect for Emdebian but it is the best we are going to get, it is immeasurably better than what we have (principally because it can support future development needs) and we need to work with it and modify it to our needs. The current layout is simply not an option. It has gone as far as it can go, it simply cannot cope with forthcoming changes within dpkg or likely future changes. There is no way to make any progress with cross-building larger parts of Debian without an unsustainable mess of multiple layers of package patches, specialised tools and horrible hacks to what should be standard tools. Perpetuating the current system will only add back layer upon layer of new hacks, to replace the ones I've been working to remove, as our methods once again fall behind core Debian methods and get left to bitrot. If that happens, there will be no way to expand Emdebian Crush. A lot of progress has been made in removing old hacks from the current tools but there is nowhere left to go. The next step is to get support into dpkg - only then can any of the bugs in apt-cross and the more complex bugs in Emdebian Crush actually get fixed. That much has been inevitable from the start. I think that it is highly unlikely that Emdebian Crush will ever be able to support more than ARM or armel (i.e. one architecture at a time) *unless* the current cross-building methods are dropped - the workload is simply too high. I do not think that is acceptable. There are problems with using multiarch, yes, but the prize is infinitely more important than the difficulties. If some things need to be adapted to work with unchanged core tools then so be it - if some things still need specialised wrappers, so be it. The aim is and has always been to get the core cross-building support into the core Debian packaging tools and that means dpkg and no dpkg-cross, it means apt and no apt-cross and it means that cross-building needs to adopt and modify multiarch to the point where we can all use it, albeit with wrappers and support tools where necessary. Then, we can work on absorbing those wrappers into the new dpkg when the time comes. Multiarch is the only deal on the table and we need to make it work, even if certain features/artefacts of the current system are lost. Please don't argue the points any further, we may lose all that we have gained so far. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgpJ1XAMaihwM.pgp Description: PGP signature
reassign 518754 to gcc-4.3, cloning 518754, reassign -1 to gcc-4.4
reassign 518754 gcc-4.3 clone 518754 -1 reassign -1 gcc-4.4 -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: freeze exception for gcc-4.5 (i386, amd64 only)
Hi Matthias, Sorry for not getting back to you sooner. On Sat, Aug 07, 2010 at 11:42:42PM +0200, Matthias Klose wrote: > gcc-4.5 should be released with squeeze, at least on amd64 and i386. > gcc-4.5.1 was released a week ago, the first bug and regression fix > release after the initial gcc-4.5.0 release. > Do you have any information as to why this is needed for squeeze, as opposed to squeeze+1? Would this be a nice-to-have, or does it solve a specific problem? > - gcc-4.5 will be an optional compiler, not replacing the current >defaults. Ok, but if it can be used, it probably will be by at least some things. > If port maintainers do want to enable gcc-4.5 on a port, they should > make sure that no regressions are introduced by building the runtime > libraries from > 4.5 and ensure that possible regressions are fixed. > This is the bit that worries me. Although it is optional, it can (and IMO will probably) be used by at least some things. This could lead to odd bugs. If there's a problem in GCC 4.5 that isn't in 4.4, and it comes to a security upload, there could be a mismatch between the requirements. Do you have details as to the (previously mentioned) unit/regression tests? Thanks, Neil -- * hermanr feels like a hedgehog having sex... -- 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/20100811211612.gf7...@halon.org.uk
Re: freeze exception for gcc-4.5 (i386, amd64 only)
On Mon, Aug 16, 2010 at 12:36:34PM +0200, Matthias Klose wrote: > On 11.08.2010 23:16, Neil McGovern wrote: > >Hi Matthias, > > > >Sorry for not getting back to you sooner. > > > >On Sat, Aug 07, 2010 at 11:42:42PM +0200, Matthias Klose wrote: > >>gcc-4.5 should be released with squeeze, at least on amd64 and i386. > >>gcc-4.5.1 was released a week ago, the first bug and regression fix > >>release after the initial gcc-4.5.0 release. > >> > > > >Do you have any information as to why this is needed for squeeze, as > >opposed to squeeze+1? Would this be a nice-to-have, or does it solve a > >specific problem? > > it's more than "nice-to-have". See the reasons in my original > posting (which you didn't include here in the reply). > I'm not sure there are any in the original, plugins and a greater optimisation level certainly aren't things which will solve specific problems. Could you highlight them for me? > >> - gcc-4.5 will be an optional compiler, not replacing the current > >>defaults. > > > >Ok, but if it can be used, it probably will be by at least some things. > > correct. but it should not introduce rc issues; if it does, then > fall back to 4.4, or don't use 4.5 in the first place. > Unless things FTBFS on some arches and not others, and thus cause delays in the freeze. > >>If port maintainers do want to enable gcc-4.5 on a port, they should > >>make sure that no regressions are introduced by building the runtime > >>libraries from > >>4.5 and ensure that possible regressions are fixed. > >> > > > >This is the bit that worries me. Although it is optional, it can (and > >IMO will probably) be used by at least some things. This could lead to > >odd bugs. If there's a problem in GCC 4.5 that isn't in 4.4, and it > >comes to a security upload, there could be a mismatch between the > >requirements. > > sorry, I don't understand this reasoning and the implications for > security uploads. If a package is explicitely built with 4.5, it > will be built with 4.5 for security uploads too. > Ok, assume that gcc4.5 has some major bug that causes FTBFSes in certain circumstances, and a package has been modified in a way to take advantage of gcc4.5, specifically so it won't build with 4.4; then a problem would occur. > >Do you have details as to the (previously mentioned) unit/regression > >tests? > > not besides the test results included in the packages prepared for > upload. Is there anything more you would expect? > You mentioned: > - the upload will build several runtime libraries from the 4.5 > sources. Regression tests did pass for the runtime libs built > from the 4.5 sources and for 4.4 using the runtime libs from > 4.5. At the moment, I'm still not sure on the actual advantage of introducing this new package at this stage in the release cycle. Neil -- * stockholm bangs head against budget outsch h01ger: it is still very soft, i did not hurt myself stockholm: But you bled on the budget, and now it's red again! -- 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/20100818143615.gn7...@halon.org.uk
Re: freeze exception for gcc-4.5 (i386, amd64 only)
On Wed, Aug 18, 2010 at 05:17:32PM +0200, Matthias Klose wrote: > >I'm not sure there are any in the original, plugins and a greater > >optimisation level certainly aren't things which will solve specific > >problems. Could you highlight them for me? > > Having these features available for developers, and having not to > wait two years until these appear in a stable release is worth the > update. Exposing a new compiler version to upstream developers > helps reducing the delta between upstream and debian packages. Yes I > think this is worth having it in squeeze. > I don't think that stable is the place for doing active development. > >You mentioned: > >>- the upload will build several runtime libraries from the 4.5 > >> sources. Regression tests did pass for the runtime libs built > >> from the 4.5 sources and for 4.4 using the runtime libs from > >> 4.5. > > This didn't answer my question. "Is there anything more you would expect?" > I was asking for details as to what these actually did. Are they just "will the binary run?" > >At the moment, I'm still not sure on the actual advantage of introducing > >this new package at this stage in the release cycle. > > well, currently I don't see any arguments against the upload, just > some feelings that could apply to any package. > That's kinda the point. These apply for any package, and especially so for a toolchain. Given that there doesn't seem to be any compelling reason for gcc4.5 in squeeze, I'm afraid it's not going to make it for this release. Apologies, Neil -- * hermanr feels like a hedgehog having sex... -- 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/20100820093451.gu7...@halon.org.uk
Re: freeze exception for gcc-4.5 (i386, amd64 only)
On Fri, 20 Aug 2010 13:07:46 +0200 Reinhard Tartler wrote: > On Fri, Aug 20, 2010 at 11:34:51 (CEST), Neil McGovern wrote: > > > On Wed, Aug 18, 2010 at 05:17:32PM +0200, Matthias Klose wrote: > >> >I'm not sure there are any in the original, plugins and a greater > >> >optimisation level certainly aren't things which will solve specific > >> >problems. Could you highlight them for me? > >> > >> Having these features available for developers, and having not to > >> wait two years until these appear in a stable release is worth the > >> update. Exposing a new compiler version to upstream developers > >> helps reducing the delta between upstream and debian packages. Yes I > >> think this is worth having it in squeeze. > >> > > > > I don't think that stable is the place for doing active development. > > stable is in the place so that (upstream) developers can develop their > applications with hopefully state-of-the art tools. To a point, but upstreams using stable also expect the dependencies to build using the stable toolchain and there are still bugs outstanding (one in my own package) where packages already in Squeeze fail to build from source with gcc-4.5. gcc-4.5 can't be the default compiler for Squeeze, so why would it be suitable to be added for only a subset when this could cause more breakage. > >> >At the moment, I'm still not sure on the actual advantage of > >> >introducing this new package at this stage in the release cycle. > >> > >> well, currently I don't see any arguments against the upload, just > >> some feelings that could apply to any package. > >> > > > > That's kinda the point. These apply for any package, and especially so > > for a toolchain. > > > > Given that there doesn't seem to be any compelling reason for gcc4.5 in > > squeeze, I'm afraid it's not going to make it for this release. > > - gcc-4.5 brings many improvements (e.g., improved C++0x support) that >help developers a lot during development. > > - applications developed with g++-4.5 require g++-4.5's runtime >library, they won't *run* with g++-4.4's libstdc++6 package. > > The second point appears very compelling to me since a considerable > demand during squeeze's lifetime can be expected because of the first > point. To me, the second point actually counts against allowing gcc-4.5 because it makes it a requirement that the entire dependency chain of a C++ program using g++-4.5 would either generate new bugs or require rebuilds using g++-4.5 merely to use the optional compiler. Stable releases need a stable toolchain with known bugs, not a comparatively untested optional compiler with compatibility issues against the existing binary packages available in Squeeze. -- Neil Williams = http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/ pgpBJSvC5RwVL.pgp Description: PGP signature
Bug#667341: test builds for template issues in qmf
Further to this issue, I've recompiled qmf in a pbuilder chroot with gcc-4.6 replacing gcc-4.7 and using compiler flags for -Wall -Wextra and -Werror in the src/libraries/qmfclient subdir and tests/tst_qmailthread/ sub directories without problems. There doesn't seem to be anything which gcc-4.6 can pick up as an error or warning in the qmf sources. Reinstalling gcc-4.7 & g++-4.7 and rebuilding with the same flags (and the #include patch) does not indicate any problems with the qmfclient library itself, g++-4.7 just fails to link the test binary. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpJl8X7Ki8QO.pgp Description: PGP signature
Bug#667341: clang tests
/home/qmf-1.0.7~2011w23.2# objdump -C -t
src/libraries/qmfclient/build/libqmfclient.so.1.0.0 |grep QMailThreadSort|grep
serial|cut -d' ' -f5-
F .text 00b3 void
MailSortKeyImpl::deserialize(QDataStream&)
F .text 01a0 void
MailSortKeyImpl::serialize(QDataStream&) const
/home/qmf-1.0.7~2011w23.2# ls -l /usr/bin/g++
lrwxrwxrwx 1 root root 7 Jul 12 15:46 /usr/bin/g++ -> clang++
# dpkg-query -W -f'${Package} ${Version}\n' clang
clang 3.1-8
The same symbols are listed with gcc-4.6.
With gcc-4.7, only the serialize symbol is listed, hence the build
fails in the test suite.
# objdump -C -t src/libraries/qmfclient/build/libqmfclient.so.1.0.0 |grep
QMailThreadSort|grep serial|cut -d' ' -f5-
F .text 00d3 void
MailSortKeyImpl::serialize(QDataStream&) const
# g++ --version
g++ (Debian 4.7.1-4) 4.7.1
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
(now trying some optimisation tests)
-- System Information:
Debian Release: wheezy/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) (ignored: LC_ALL set to C)
Shell: /bin/sh linked to /bin/dash
Versions of packages gcc-4.7 depends on:
ii binutils 2.22-7
ii cpp-4.7 4.7.1-4
ii gcc-4.7-base 4.7.1-4
ii libc6 2.13-34
ii libgcc1 1:4.7.1-4
ii libgmp10 2:5.0.5+dfsg-2
ii libgomp1 4.7.1-4
ii libitm1 4.7.1-4
ii libmpc2 0.9-4
ii libmpfr4 3.1.0-5
ii libquadmath0 4.7.1-4
ii zlib1g1:1.2.7.dfsg-13
Versions of packages gcc-4.7 recommends:
ii libc6-dev 2.13-34
Versions of packages gcc-4.7 suggests:
pn binutils-gold
pn gcc-4.7-doc
pn gcc-4.7-locales
pn gcc-4.7-multilib
pn libgcc1-dbg
pn libgomp1-dbg
pn libitm1-dbg
pn libmudflap0-4.7-dev
pn libmudflap0-dbg
pn libquadmath0-dbg
-- no debconf information
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpjgG0ceHZ4O.pgp
Description: PGP signature
Bug#667341: optimisation tests
Dropping the optimisation on src/libraries/qmfclient/ from -O2 to -O1 fixes the
issue:
# objdump -C -t src/libraries/qmfclient/build/libqmfclient.so.1.0.0 |grep
QMailThreadSort|grep serial|cut -d' ' -f5-
F .text 0012 void
QMailThreadSortKey::serialize(QDataStream&) const
F .text 00a1 void
MailSortKeyImpl::deserialize(QDataStream&)
F .text 0048 void
QMailThreadSortKey::deserialize(QDataStream&)
F .text 00cb void
MailSortKeyImpl::serialize(QDataStream&) const
.. albeit defining a pair of new symbols...
The functions themselves are public.
class QMF_EXPORT QMailThreadSortKey
{
public:
enum Property
{
Id,
ServerUid
};
typedef QMailSortKeyArgument ArgumentType;
public:
bool isEmpty() const;
const QList &arguments() const;
template void serialize(Stream &stream) const;
template void deserialize(Stream &stream);
Why is gcc-4.7 overriding the class and optimising away a public symbol
in -O2 when it does not in -O1 or in gcc-4.6 with -O2?
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
pgpVJo4UKVg7b.pgp
Description: PGP signature
Bug#667341: optimisation tests
On Sat, 14 Jul 2012 20:12:45 +0200
Matthias Klose wrote:
> On 14.07.2012 20:02, Neil Williams wrote:
> > On Sat, 14 Jul 2012 03:08:09 +0200 Matthias Klose wrote:
> >
> >> please could you find out, which object files (if there are more than
> >> one) do export this symbol for a -O1 build, and attach the preprocessed
> >> source and command line options for these file(s)?
> >
> > shell script and gzip'd pre-processed cpp file attached. I've tested in a
> > clean pbuilder chroot and the results for gcc-4.7 demonstrate the bug:
> [...]
> > objdump -C -t libqmfclient.so.1.0.0|grep deserialize
>
> no, the dump/grep is needed for each .o file in libqmfclient.so.1.0.0. and the
> preprocessed source for each matching .o file.
There is only one .o file needed for this test, so the adapted script
is attached. The pre-processed cpp doesn't change with optimisation.
Output also attached.
--
Neil Williams
=
http://www.linux.codehelp.co.uk/
#!/bin/sh
# Debug support for #667341
set -e
run () {
LIBDIR=`dpkg-architecture -qDEB_HOST_MULTIARCH`
if [ -f qmailthreadsortkey.o ]; then
rm qmailthreadsortkey.o
fi
if [ -f libqmfclient.so.1.0.0 ]; then
rm libqmfclient.so.1.0.0
fi
# Checking pre-processed cpp file
echo "Checking pre-processed cpp file"
grep "QMailThreadSortKey::deserialize" qmailthreadsortkey.cpp
# Line for pre-processed cpp file
g++ -c -pipe ${OPTS} -Wall -W -fPIC -o qmailthreadsortkey.o qmailthreadsortkey.cpp
echo "Checking for deserialize symbol in object file:"
objdump -C -t qmailthreadsortkey.o|grep deserialize|c++filt
# original line which needs libqt4-dev installed
#g++ -c -pipe ${OPTS} -Wall -W -D_REENTRANT -fPIC -DQT_WEBKIT -DQT_BUILD_QCOP_LIB -DQMF_INTERNAL -DQT_NO_DEBUG -DQT_SQL_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++ -I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtNetwork -I/usr/include/qt4/QtSql -I/usr/include/qt4 -Isupport -I. -o qmailthreadsortkey.o qmailthreadsortkey.cpp
# Line for pre-processed cpp file
g++ -Wl,${OPTS} -shared -Wl,-soname,libqmfclient.so.1 -o libqmfclient.so.1.0.0 qmailthreadsortkey.o -L/usr/lib/${LIBDIR} -lpthread
# original line (shortened) which needs libqt4-dev installed
#g++ -Wl,${OPTS} -shared -Wl,-soname,libqmfclient.so.1 -o libqmfclient.so.1.0.0 qmailthreadsortkey.o -L/usr/lib/${LIBDIR} -lQtSql -lQtNetwork -lQtCore -lpthread
echo "Checking for deserialize symbol in library:"
objdump -C -t libqmfclient.so.1.0.0|grep deserialize|c++filt
}
echo "Starting with -O1"
OPTS="-O1"
run
echo "Changing to -O2"
OPTS="-O2"
run
output
Description: Binary data
pgpWfikFd4TpW.pgp
Description: PGP signature
Bug#553047: More info - no such file libc-2.10.1.so after a build in chroot
gcc (2.95.1-1) unstable; urgency=low
* debian/rules2 [binary-arch]: Call dh_shlibdeps with LD_LIBRARY_PATH
set to installation dir of libstdc++. Why isn't this the default?
-- Matthias Klose Sat, 28 Aug 1999 18:16:31 +0200
So the question is why this is new.
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+
$LD_LIBRARY_PATH:}/usr/powerpc-linux-gnu/lib ARCH=powerpc
MAKEFLAGS="CC=something" dh_shlibdeps -plibgcc1-powerpc-cross
error while loading shared
libraries: /usr/powerpc-linux-gnu/lib/libc.so.6: ELF file data encoding
not little-endian
i.e. dh_shlibdeps might not listening to ARCH but is taking the
underlying system as the base from which to determine the endianness it
should check. It's reading the i386 endianness and complaining that
powerpc isn't the same endianness. Ooops. Alternatively, see the end of
this email - dh_shlibdeps might actually be tripping over a file that
should not exist in the build environment at all.
The URLs didn't work - I'm looking at:
http://www.emdebian.org/~zumbi/toolchain/i386-unstable/logs/i386-powerpc-4.4.log
http://www.emdebian.org/~zumbi/toolchain/i386-unstable/logs/i386-powerpc-4.3.log
It doesn't help that I'm using the toolchains for Lenny but have to get
binutils-powerpc-linux-gnu from sid as a build-dep for gcc-4.4 but
I've just build gcc-4.3-powerpc-linux-gnu OK in the same chroot and
then upgrading binutils-powerpc-linux-gnu again to 2.20.1-3 for 4.4.
However, I get a different error:
sed s/-powerpc-cross//g < debian/lib64gomp1-powerpc-cross/DEBIAN/shlibs
> debian/lib64gomp1-powerpc-cross/DEBIAN/shlibs.fixed /bin/bash:
> debian/lib64gomp1-powerpc-cross/DEBIAN/shlibs: No such file or
> directory
In particular, dh_shlibdeps works:
dh_makeshlibs -plibgcc1-powerpc-cross -n
sed s/-powerpc-cross//g < debian/libgcc1-powerpc-cross/DEBIAN/shlibs >
debian/libgcc1-powerpc-cross/DEBIAN/shlibs.fixed
mv debian/libgcc1-powerpc-cross/DEBIAN/shlibs.fixed
debian/libgcc1-powerpc-cross/DEBIAN/shlibs
cat debian/libgcc1-powerpc-cross/DEBIAN/shlibs >> debian/shlibs.local
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}/usr/powerpc-linux-gnu/lib
ARCH=powerpc MAKEFLAGS="CC=something" dh_shlibdeps -plibgcc1-powerpc-cross
sed -i 's...@[ =]lib[^ ,]*@&-powerpc-cr...@g'
debian/libgcc1-powerpc-cross.substvars
and continues on to:
dh_makeshlibs -plibgomp1-powerpc-cross
sed s/-powerpc-cross//g < debian/libgomp1-powerpc-cross/DEBIAN/shlibs >
debian/libgomp1-powerpc-cross/DEBIAN/shlibs.fixed
mv debian/libgomp1-powerpc-cross/DEBIAN/shlibs.fixed
debian/libgomp1-powerpc-cross/DEBIAN/shlibs
LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}/usr/powerpc-linux-gnu/lib
ARCH=powerpc MAKEFLAGS="CC=something" dh_shlibdeps -plibgomp1-powerpc-cross
sed 's/\(lib[^ ]*\) /\1-powerpc-cross /g' <
debian/libgomp1-powerpc-cross.substvars >
debian/libgomp1-powerpc-cross.substvars.new
mv debian/libgomp1-powerpc-cross.substvars.new
debian/libgomp1-powerpc-cross.substvars
and thence to:
dh_installdirs -plib64gomp1-powerpc-cross \
usr/lib64
DH_COMPAT=2 dh_movefiles -plib64gomp1-powerpc-cross \
usr/lib64/libgomp.so.*
dh_movefiles: Compatibility levels before 5 are deprecated.
debian/dh_doclink -plib64gomp1-powerpc-cross gcc-4.4-powerpc-linux-gnu-base
WARNING: removing doc directory lib64gomp1-powerpc-cross
dh_strip -plib64gomp1-powerpc-cross #--dbg-package=lib64gomp1-dbg
dh_compress -plib64gomp1-powerpc-cross #-plib64gomp1-dbg
dh_fixperms -plib64gomp1-powerpc-cross #-plib64gomp1-dbg
dh_makeshlibs -plib64gomp1-powerpc-cross
sed s/-powerpc-cross//g < debian/lib64gomp1-powerpc-cross/DEBIAN/shlibs >
debian/lib64gomp1-powerpc-cross/DEBIAN/shlibs.fixed
/bin/bash: debian/lib64gomp1-powerpc-cross/DEBIAN/shlibs: No such file or
directory
I used:
# GCC_TARGET=powerpc DEB_CROSS=yes fakeroot debian/rules control
# DEB_CROSS_NO_BIARCH=yes GCC_TARGET=powerpc DEB_CROSS=yes dpkg-buildpackage
-us -uc -rfakeroot
Hector: problem is, I don't have the
file /usr/powerpc-linux-gnu/lib/libc-2.10.1.so after the build or as a
result of installing the necessary build dependencies.
r...@dwarf:~/gcc-4.4-4.4.3# file /usr/powerpc-linux-gnu/lib/libc-2.10.1.so
/usr/powerpc-linux-gnu/lib/libc-2.10.1.so: ERROR: cannot open
`/usr/powerpc-linux-gnu/lib/libc-2.10.1.so' (No such file or directory)
It's not a file in Debian sid either (crossed or native):
You have searched for paths that end with libc-2.10.1.so in suite sid, all
sections, and all architectures.
Sorry, your search gave no results
http://www.uk.debian.org/distrib/packages#search_contents
As the file isn't in Debian, dpkg-cross wouldn't normally have created
a package to put the file into /usr/powerpc-linux-gnu/lib/
Question is, where did this file come from?
I can check the chroot on emdebian.org - I just need to know which one
was used.
Could this be a resul
Re: sh4 architecture into Wheezy
On Tue, Apr 26, 2011 at 12:58:24PM +0900, Nobuhiro Iwamatsu wrote: > > We don't have faster hardware. > > We think of a too slow thing in a question > > A test of gcc of sh4 takes time. > When there is not a test, a package is done in about two days. > > How does sh4 become targeted for the release architecture? > Can sh4 disable gcc test? > I woudn't be particularly happy with that unless the gcc maintainers ok it, and I'm still not sure that two days is also an acceptable timescale. Have you tried a SH4A with a dual core? At the moment, I think that this issue is severe enough that it can't be a release architecture. (Note that if it is solved, there may be other problems, but we can get to those later.) Neil -- A. Because it breaks the logical sequence of discussion Q. Why is top posting bad? gpg key - http://www.halon.org.uk/pubkey.txt ; the.earth.li A40F862E -- 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/20110426073922.gc7...@feta.halon.org.uk
Bug#633365: libppl-swi: Getting rid of unneeded *.la / emptying dependency_libs
Package: libppl-swi Version: 0.11.2-3 Severity: normal User: codeh...@debian.org Usertags: la-file-removal To finish an old release goal from Squeeze, to comply with Policy 10.2 and to ease the introduction of MultiArch, I'm filing bugs against packages which contain .la files which can be either removed or stripped of the dependency_libs variable. http://wiki.debian.org/ReleaseGoals/LAFileRemoval http://lists.debian.org/debian-devel/2011/04/msg00055.html http://lists.debian.org/debian-devel/2011/04/msg00199.html Data has been obtained from the output of an automated script: http://release.debian.org/~aba/la/current.txt The output is best read in conjunction with the criteria from this post to debian-devel: http://lists.debian.org/debian-devel/2009/08/msg00808.html To generate the list of packages, I've used: grep -v depended-on current.txt |cut -d: -f1 The data is regularly updated but please accept my apologies if you have made an upload which changes the situation since the data was parsed. libppl-swi (0.11.2-3) appears in this list as a source package because one or more of the binary packages (usually -dev packages) contain .la files. In this case, the .la file is in libppl-swi: /usr/lib/ppl/libppl_swiprolog.la # Libraries that this one depends upon. dependency_libs=' /usr/lib/libppl.la -L/usr/lib /usr/lib/libpwl.la /usr/lib/libgmpxx.la /usr/lib/libgmp.la' In most cases, the .la file(s) can simply be removed as the process behind this MBF has already identified that there are no further dependencies using the .la file. In the unusual case that your package uses libltdl directly, it is still necessary to empty the dependency_libs part of all .la files remaining in the package. If you believe that your package needs both the .la file and the dependency_libs settings, please raise this on debian-devel for clarification. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpWFqMTKvwXH.pgp Description: PGP signature
Bug#431086: please support reverse cross build
Package: gcc-4.2 Version: 4.2-20070627-1 Severity: normal Tags: patch On Thu, 28 Jun 2007 14:47:55 +0200 Martin Michlmayr <[EMAIL PROTECTED]> wrote: > Throughout the development of GCC 4.2, we regularly recompiled the > entire Debian archive with development snapshots of GCC to make sure > that we'd end up with a reliable compiler. We have done regular > rebuilds on IA64 and AMD64, and we have tested almost every > architecture at some point during the development phase of 4.2 (the > exception being hppa and m68k, as well as non-Linux platforms). We > now have a compiler with relatively few known issues. One issue that arose during DebConf7 relates to an upstream behaviour of gcc that is not working inside the debian packaging code. Emdebian has been building cross-compiler toolchains for some time but in order to be able to build all Emdebian packages from source, we need to be able to cross build gcc, not to provide a cross compiler but to provide some core libraries - specifically libgcc1 and libstsdc++6-foo - cross built for a different host. e.g. Build=amd64|i386|powerpc Host=arm Target=arm compared to build=amd64|i386|powerpc host=amd64|i386|powerpc target=arm for a standard cross-compiler. As host==target this isn't a full canadian cross, more of a reverse cross. A normal arm-linux-gnu-gcc etc. toolchain is used to build these packages. The attached patches to debian/rules.defs and debian/rules2 provide support for these builds as well as outline support for a full canadian cross build. --- System information. --- Architecture: amd64 Kernel: Linux 2.6.21-1-amd64 Debian Release: lenny/sid 500 unstablewww.linux.codehelp.co.uk 500 unstablewww.emdebian.org 500 unstableftp.uk.debian.org --- Package information. --- Depends (Version) | Installed ==-+-== gcc-4.2-base(= 4.2-20070627-1) | 4.2-20070627-1 cpp-4.2 (= 4.2-20070627-1) | 4.2-20070627-1 binutils (>= 2.17cvs20070426) | 2.17cvs20070426-8 libgcc1 (>= 1:4.2-20070627-1) | 1:4.2-20070627-1 libgomp1 (>= 4.2-20070627-1) | 4.2-20070627-1 libc6 (>= 2.5-5) | 2.5-11 -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ --- gcc-4.2.old/debian/rules.defs 2007-06-29 12:34:25.0 +0100 +++ gcc-4.2.cross/debian/rules.defs 2007-06-29 16:10:04.0 +0100 @@ -66,6 +66,28 @@ endif # --- +# full canadian +# typical cross-compiler +# reverse cross (built to run on the target) +# native +# +# build != host && host == target : reverse cross (REVERSE_CROSS == yes) +# build == host && host != target : typical cross (DEB_CROSS == yes) +# build != host && host != target : canadian (DEB_CROSS == yes) +# build == host && host == target : native +ifneq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE)) + ifneq ($(DEB_HOST_GNU_TYPE), $(DEB_TARGET_GNU_TYPE)) + DEB_CROSS = yes + else + REVERSE_CROSS = yes + endif + else + ifneq ($(DEB_HOST_GNU_TYPE), $(DEB_TARGET_GNU_TYPE)) + DEB_CROSS = yes + endif +endif + +# --- # which binary packages are built? # cross compiler support. If GCC_TARGET is set, then it's the architecture @@ -75,8 +97,7 @@ $(error GCC_TARGET value "$(GCC_TARGET)" is not a valid Debian architecture) endif -ifneq ($(DEB_HOST_GNU_TYPE),$(DEB_TARGET_GNU_TYPE)) - DEB_CROSS = yes +ifdef DEB_CROSS # TP: Target Prefix. Used primarily as a prefix for cross tool # names (e.g. powerpc-linux-gcc). # TS: Target Suffix. Used primarily at the end of cross compiler @@ -700,6 +721,9 @@ ifdef DEB_CROSS with_check := disabled for cross compiler package endif +ifdef REVERSE_CROSS + with_check := disabled for reverse cross build +endif check_no_systems := hurd-i386 ifneq (, $(filter $(DEB_TARGET_GNU_SYSTEM),$(check_no_systems))) with_check := disabled for $(DEB_TARGET_GNU_SYSTEM) --- gcc-4.2.old/debian/rules2 2007-06-29 12:34:25.0 +0100 +++ gcc-4.2.cross/debian/rules2 2007-06-29 16:03:57.0 +0100 @@ -535,7 +535,9 @@ $(build_stamp): $(configure_stamp) $(build_locale_stamp) dh_testdir rm -f bootstrap-protocol +# DEB_CROSS is never set if REVERSE_CROSS is set and vice-versa. ifndef DEB_CROSS +ifndef REVERSE_CROSS ifeq ($(with_java),yes) ifeq ($(with_native_ecj),yes) : # prepare the standalone ecj jar @@ -608,6 +610,7 @@ ) 2>&1 | tee bootstrap-protocol s=`cat status`; rm -f status; test $$s -eq 0 endif +endif -chmod 755 $(srcdir)/contrib/warn_summary if [ -x $(srcdir)/contrib/warn_summary ]; then \ rm -f bootstrap-summary; \ pgpPpxrKiTnZM.pgp Description: PGP signature
Re: GCC 4.2 transition
On Fri, Jul 20, 2007 at 11:51:47AM +0200, Mike Hommey wrote:
> On Fri, Jul 20, 2007 at 11:33:01AM +0200, Johannes Berg <[EMAIL PROTECTED]>
> wrote:
> > On Fri, 2007-07-20 at 10:16 +0200, Matthias Klose wrote:
> >
> > > Does any port still need to stick with GCC 4.1 for a while? Feedback
> > > from hppa, mips*, s390, powerpc, amd64, i386 porters doesn't show
> > > objections against the transition.
> >
> > I have objections :)
> > http://bugs.debian.org/433629
> > Yes, it's pretty odd, but recompiling the whole kernel tree with gcc 4.2
> > causes my usbhid to totally not work.
>
> I have another objection. I'd like all mozilla security updates to be built
> before gcc 4.2 becomes the default, because they don't build correctly yet,
> and I am (still) waiting for an upstream comment on how to fix it.
>
On a more general note, I'd like to see xulrunner/nss built and
depending packages[0] built so we can get the fixes into testing easier
before this is started.
Cheers,
Neil
[0] Most of: http://security-tracker.debian.net/tracker/status/dtsa-candidates
--
int getRandomNumber() {
return 4; // chosen by fair dice roll. guaranteed to be random.
}
// http://xkcd.com/c221.html
signature.asc
Description: Digital signature
Bug#414099: gcc-4.1: cross build failure: debug package not built when cross compiling
On Mon, 17 Sep 2007 00:46:49 +0200 Jö Fahlke <[EMAIL PROTECTED]> wrote: > I don't currently have a powerpc machine up and running, so I won't > be able to test the resulting compiler very much. Also, I've switched > to lenny in the meantime. For building the pakage, I'm using > > * dpkg-cross 1.39 Currently being re-written. 1.99+2.0.0pre1 is in experimental, pre2 is pending changes in dpkg. The rest of the issues are all to do with gcc-4.2, not dpkg-cross. > * libgcc1-powerpc-cross is needed to cross-build gcc-4.2 since the > libc stuff depends on it. libc6-foo-cross to be precise. > However, cross-building gcc will produce > another version of libgcc1-powerpc-cross. The version produced by > dpkg-cross depends on gcc-4.2-base-powerpc-cross, while the other > version depends on gcc-4.2-powerpc-linux-gnu-base, which was > produced in the cross-build. You've missed a trick with the dpkg-cross one - use the '-X' option to exclude Architecture:all packages or use apt-cross to download, build and install libgcc1-foo-cross in one operation so that the dependency is omitted. dpkg-cross (like dpkg) isn't aware of the detail of a dependency - it just knows the name. apt-cross uses the apt cache to retrieve data (like whether it is Architecture:all) and uses that data to make sensible decisions about which dependencies are relevant to dpkg-cross and passes the '-X' option for the others. When building Emdebian toolchains, we install libgcc1 (amongst others) using apt-cross, then build binutils and gcc, then install in one operation. Try checking the source code of emchain from emdebian-tools. -- Neil Williams = http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/ pgp2YDoqyvZRe.pgp Description: PGP signature
Bug#769797: marked as done (gnat-4.9: FTBFS: Needs update for gcc-4.9-4.9.2)
On Mon, 19 Jan 2015 11:45:28 +0100 Matthias Klose wrote: > reopen 769797 > found 769797 4.9.1-4 > thanks > > On 01/18/2015 11:51 AM, Debian Bug Tracking System wrote: > > Your message dated Sun, 18 Jan 2015 10:46:31 + > > with message-id <20150118104631.13a3ecaf@sylvester.codehelp> > > and subject line No longer found > > has caused the Debian Bug report #769797, > > regarding gnat-4.9: FTBFS: Needs update for gcc-4.9-4.9.2 > > to be marked as done. > > unless you tell me how the b-d > > gcc-4.9-source (<< 4.9.2) > > is satisfied in unstable, please leave this issue open. That doesn't make sense. gnat-4.9 in unstable has build-dependencies which can be satisfied in unstable. gnat-4.9 in testing has build-dependencies which can be satisfied in testing. Why would the build-dependency gcc-4.9-source (<< 4.9.2) in gnat-4.9 in *testing* be relevant when checked in unstable? gnat-4.9 in testing does build just fine, in testing, so the bug title is - at least - inaccurate. There is no FTBFS in gnat-4.9 4.9.1-4 unless trying to build in unstable - which is unnecessary because Policy doesn't require that packages in testing build in unstable - it does that the packages in testing build in testing. In my tests, that requirement is met. What is the actual purpose of this bug? Why is a build-dependency constraint in testing relevant to builds in unstable? It's not as if gnat-4.9 is about to migrate into testing, even then the new version would migrate with the constraints met. -- Neil Williams = http://www.linux.codehelp.co.uk/ pgpbnbEwmKcfw.pgp Description: OpenPGP digital signature
Re: preprocessor/2881: code inside "#if 0" generates warnings with -pedantic
Markus F.X.J. Oberhumer wrote:- > #if 0 > // int bar =3D 1; > #endif Zack, what's you opinion of this? Whether we accept the // can affect tokenisation, which must still be valid in skipped blocks. In other words, acceptance of #if 0 // ' #endif depends upon whether we accept //. I'm tempted to leave it as it is, but we can turn of the warning if you think it's inappropriate. Neil.
[Bug c/29468] off-by-one error for string initialiser warning
--- Comment #1 from neil at gcc dot gnu dot org 2006-10-14 12:25 --- Not a bug - just 2 elements are initialized, the NUL is dropped. -- neil at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29468 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug c/11459] -stdc=c99 -pedantic -ansi warns about C90's non long-long support when in C99 mode
PLEASE REPLY TO [EMAIL PROTECTED] ONLY, *NOT* [EMAIL PROTECTED] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11459 --- Additional Comments From neil at daikokuya dot co dot uk 2003-07-09 05:45 --- Subject: Re: -stdc=c90 -pedantic -ansi warns about C90's non long-long support when in C99 mode pinskia at physics dot uc dot edu wrote:- > pinskia at physics dot uc dot edu changed: > >What|Removed |Added > > Summary|-stdc=c90 -pedantic warns |-stdc=c90 -pedantic -ansi >|about C90's non long-long |warns about C90's non long- >|support when in C99 mode|long support when in C99 >||mode > > > --- Additional Comments From pinskia at physics dot uc dot edu > 2003-07-08 20:11 --- > The bug report is wrong because with those options, I do not get the warning > but reading > the bug report which is this is forward from, I see that the option -ansi is > there, I do not > know what is should happen when you say '-std=c99 -ansi' or '-ansi -std=c99', > should gcc > put into c89 or c99? Could some else look at this bug and say what should > gcc do? -ansi means -std=c89. Which ever comes later of -ansi and -std=c99 should win; this is the general rule (sadly some exceptions are insisted on). Neil. --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
Bug#122103: [Bug c/9071] Warning for blocks not closed in same file as opened in
-- What|Removed |Added Component|preprocessor|c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9071 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
[Bug c/9071] Warning for blocks not closed in same file as opened in
--- Additional Comments From neil at gcc dot gnu dot org 2004-02-04 10:26 --- Nothing to do with CPP. -- What|Removed |Added Component|preprocessor|c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9071 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
