java-gcj-compat_1.0.65-1_powerpc.changes ACCEPTED

[Debian Installer]

Accepted:
java-gcj-compat-dev_1.0.65-1_powerpc.deb
  to pool/main/j/java-gcj-compat/java-gcj-compat-dev_1.0.65-1_powerpc.deb
java-gcj-compat-plugin_1.0.65-1_powerpc.deb
  to pool/main/j/java-gcj-compat/java-gcj-compat-plugin_1.0.65-1_powerpc.deb
java-gcj-compat_1.0.65-1_powerpc.deb
  to pool/main/j/java-gcj-compat/java-gcj-compat_1.0.65-1_powerpc.deb


Override entries for your package:
java-gcj-compat-dev_1.0.65-1_powerpc.deb - optional devel
java-gcj-compat-plugin_1.0.65-1_powerpc.deb - optional interpreters
java-gcj-compat_1.0.65-1_powerpc.deb - optional interpreters



Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

java-gcj-compat_1.0.65-1_amd64.changes ACCEPTED

[Debian Installer]

Accepted:
java-gcj-compat-dev_1.0.65-1_amd64.deb
  to pool/main/j/java-gcj-compat/java-gcj-compat-dev_1.0.65-1_amd64.deb
java-gcj-compat-plugin_1.0.65-1_amd64.deb
  to pool/main/j/java-gcj-compat/java-gcj-compat-plugin_1.0.65-1_amd64.deb
java-gcj-compat_1.0.65-1_amd64.deb
  to pool/main/j/java-gcj-compat/java-gcj-compat_1.0.65-1_amd64.deb


Override entries for your package:
java-gcj-compat-dev_1.0.65-1_amd64.deb - optional devel
java-gcj-compat-plugin_1.0.65-1_amd64.deb - optional interpreters
java-gcj-compat_1.0.65-1_amd64.deb - optional interpreters



Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processing of java-gcj-compat_1.0.65-1_amd64.changes

[Archive Administrator]

java-gcj-compat_1.0.65-1_amd64.changes uploaded successfully to localhost
along with the files:
  java-gcj-compat-dev_1.0.65-1_amd64.deb
  java-gcj-compat_1.0.65-1_amd64.deb
  java-gcj-compat-plugin_1.0.65-1_amd64.deb

Greetings,

Your Debian queue daemon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processing of java-gcj-compat_1.0.65-1_powerpc.changes

[Archive Administrator]

java-gcj-compat_1.0.65-1_powerpc.changes uploaded successfully to localhost
along with the files:
  java-gcj-compat-dev_1.0.65-1_powerpc.deb
  java-gcj-compat_1.0.65-1_powerpc.deb
  java-gcj-compat-plugin_1.0.65-1_powerpc.deb

Greetings,

Your Debian queue daemon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

java-gcj-compat_1.0.65-1_hppa.changes ACCEPTED

[Debian Installer]

Accepted:
java-gcj-compat-dev_1.0.65-1_hppa.deb
  to pool/main/j/java-gcj-compat/java-gcj-compat-dev_1.0.65-1_hppa.deb
java-gcj-compat-plugin_1.0.65-1_hppa.deb
  to pool/main/j/java-gcj-compat/java-gcj-compat-plugin_1.0.65-1_hppa.deb
java-gcj-compat_1.0.65-1_hppa.deb
  to pool/main/j/java-gcj-compat/java-gcj-compat_1.0.65-1_hppa.deb


Override entries for your package:
java-gcj-compat-dev_1.0.65-1_hppa.deb - optional devel
java-gcj-compat-plugin_1.0.65-1_hppa.deb - optional interpreters
java-gcj-compat_1.0.65-1_hppa.deb - optional interpreters



Thank you for your contribution to Debian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processing of java-gcj-compat_1.0.65-1_hppa.changes

[Archive Administrator]

java-gcj-compat_1.0.65-1_hppa.changes uploaded successfully to localhost
along with the files:
  java-gcj-compat-dev_1.0.65-1_hppa.deb
  java-gcj-compat_1.0.65-1_hppa.deb
  java-gcj-compat-plugin_1.0.65-1_hppa.deb

Greetings,

Your Debian queue daemon


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#385732: gcc-defaults: Non-free files in source package

[Sven Joachim]

Matthias Klose wrote:


The source package still contains the non-free files fsf-funding.7,


ok.


gfdl.7 and gpl.7, apparently for no good reason since they aren't
installed.  Please remove them.


no, license texts can be included. there's no reason to remove them.


But the GFDL is not the license for any package built from gcc-defaults,
so why should it be in the source package?  Having the GPL text is ok,
but it is a bit odd that it's a man page rather than plain text.



--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing

[Dirk Eddelbuettel]

On 22 August 2006 at 07:29, Dirk Eddelbuettel wrote:
| 
| On 19 August 2006 at 15:03, Matthias Klose wrote:
| | Dirk Eddelbuettel writes:
| | > 
| | > On 18 August 2006 at 00:58, Martin Michlmayr wrote:
| | > | * John Schmidt <[EMAIL PROTECTED]> [2006-08-17 13:46]:
| | > | > Is there a way for me to instrument my code/system, etc to indicate
| | > | > where the big time sink is?
| | > | 
| | > | I'm not sure but I'll try to investigate.
| | > 
| | > I didn't make that as clear as I wanted to in my last email -- but you 
could
| | > just compare the package build of RQuantLib on stable (where it should be 
few
| | > minutes) to testing (where it will be at least twice that). Not that much
| | > code in Quantlib or RQuantLib and you should get a quick feeling for how 
much
| | > g++ changed.
| | 
| | please identify the files, which take longer to build; it's known that
| | 4.x is slower in some cases.
| 
| 
| As I wrote in previous messages, the worst offender is the linking stage
| which takes several times as long as usual.  On my dual Athlon (1.5 Ghz each,
| 2gb ram total) the linking of the rather small rquantlib.so takes over eight
| minutes which is totally ridiculous.  It used to be one, at the most two,
| minutes. 

I never heard any follow-up. Is there any?  While it is nice that 4.1.1-11 is
now in testing it is not so nice that 4.1.1-11 exhibits the slow builds John
and I have been experiencing -- on different code bases, no less.

Is that the status quo or can we expect improvements at some point?

Thanks, Dirk

| 
| Thanks,  
| 
| Dirk (on vacation)
| 
| -- 
| Hell, there are no rules here - we're trying to accomplish something. 
|   -- Thomas A. Edison

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Welcome to Al-Manahel Newsletter List

[munir]

The subscription of the email address: 

[EMAIL PROTECTED]

To the mailing list: 

Al-Manahel Newsletter List

is all set. Thanks for subscribing! 

Date of this subscription: Sun Sep  3 06:38:25 2006

Please save this email message for future reference. 

---

You may automatically unsubscribe from this list at any time by 
visiting the following URL:



If the above URL is inoperable, make sure that you have copied the 
entire address. Some mail readers will wrap a long URL and thus break
this automatic unsubscribe mechanism. 

You may also change your subscription by visiting this list's main screen: 



If you're still having trouble, please contact the list owner at: 



The following physical address is associated with this mailing list: 



- 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Al-Manahel Newsletter List Unsubscription

[munir]

The removal of the email address:

[EMAIL PROTECTED]

>From the mailing list: 

Al-Manahel Newsletter List 

is all set.

Date of this removal: Sun Sep  3 06:43:04 2006

Please save this email message for future reference.

---

You may automatically subscribe from this list at any time by 
visiting the following URL:



If the above URL is inoperable, make sure that you have copied the 
entire address. Some mail readers will wrap a long URL and thus break
this automatic unsubscribe mechanism. 

You may also change your subscription by visiting this list's main screen: 



If you're still having trouble, please contact the list owner at: 



The following physical address is associated with this mailing list: 



- 



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing

[Martin Michlmayr]

* Dirk Eddelbuettel <[EMAIL PROTECTED]> [2006-09-03 06:47]:
> I never heard any follow-up. Is there any?  While it is nice that 4.1.1-11 is
> now in testing it is not so nice that 4.1.1-11 exhibits the slow builds John
> and I have been experiencing -- on different code bases, no less.

I briefly looked at it, didn't see anything obvious and then ran out
of time.  I also don't really have the right expertise for this.

> Is that the status quo or can we expect improvements at some point?

For 4.1 probably not; it'd be possible for 4.2 but you'd need to come
up with some kind of (small) testcase.
-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing

[Martin Michlmayr]

* Dirk Eddelbuettel <[EMAIL PROTECTED]> [2006-09-03 09:16]:
> | up with some kind of (small) testcase.
> 
> As John and I stated, 'small' is hard to define in the context of large-ish
> C++ applications / libraries.  The C++ source of RQuantLib are small (around
> 60kb) and I could probably trim that further for an example ... but it would
> still need QuantLib itself which is rather larger.  Would that be helpful or
> not?

s/small/self-contained/ then.  Do you have some example where the
linking process of some c++ files takes ages, without linking them
against some external library?  That would make things much easier
imho.
-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing

[Dirk Eddelbuettel]

On 3 September 2006 at 14:40, Martin Michlmayr wrote:
| * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2006-09-03 06:47]:
| > I never heard any follow-up. Is there any?  While it is nice that 4.1.1-11 
is
| > now in testing it is not so nice that 4.1.1-11 exhibits the slow builds John
| > and I have been experiencing -- on different code bases, no less.
| 
| I briefly looked at it, didn't see anything obvious and then ran out
| of time.  I also don't really have the right expertise for this.
| 
| > Is that the status quo or can we expect improvements at some point?
| 
| For 4.1 probably not; it'd be possible for 4.2 but you'd need to come
| up with some kind of (small) testcase.

As John and I stated, 'small' is hard to define in the context of large-ish
C++ applications / libraries.  The C++ source of RQuantLib are small (around
60kb) and I could probably trim that further for an example ... but it would
still need QuantLib itself which is rather larger.  Would that be helpful or
not?

I have no clue what parts of QuantLib itself cause the compiler and linker to
go gaga. You'd need a real C++ export to figure that out. I am CCing one --
who is also a key developer of QuantLib.  

Hth, Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing

[Dirk Eddelbuettel]

On 3 September 2006 at 16:27, Martin Michlmayr wrote:
| * Dirk Eddelbuettel <[EMAIL PROTECTED]> [2006-09-03 09:16]:
| > | up with some kind of (small) testcase.
| > 
| > As John and I stated, 'small' is hard to define in the context of large-ish
| > C++ applications / libraries.  The C++ source of RQuantLib are small (around
| > 60kb) and I could probably trim that further for an example ... but it would
| > still need QuantLib itself which is rather larger.  Would that be helpful or
| > not?
| 
| s/small/self-contained/ then.  Do you have some example where the
| linking process of some c++ files takes ages, without linking them
| against some external library?  That would make things much easier
| imho.

I agree. But as I am unsure excactly what part in the area of templates and
static initialization (or some variant thereof) causes this, I have to defer
to Luigi.

But yes, a smaller self-contained testcase would obviously help our case.

Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: [bts-link] source package gcc-4.1

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> #
> # bts-link upstream status pull for source package gcc-4.1
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> user [EMAIL PROTECTED]
Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]).
> # remote status report for #356548
> #  * http://gcc.gnu.org/PR26670
> #  * remote status changed: ASSIGNED -> RESOLVED
> #  * remote resolution changed: (?) -> FIXED
> #  * closed upstream
> tags 356548 + fixed-upstream
Bug#356548: FTBFS with G++ 4.1: on mips: error: cannot bind packed field
Tags were: upstream
Tags added: fixed-upstream

> usertags 356548 - status-ASSIGNED
Bug#356548: FTBFS with G++ 4.1: on mips: error: cannot bind packed field
Usertags were: status-ASSIGNED.
Usertags are now: .
> usertags 356548 + status-RESOLVED resolution-FIXED
Bug#356548: FTBFS with G++ 4.1: on mips: error: cannot bind packed field
There were no usertags set.
Usertags are now: resolution-FIXED status-RESOLVED.
> # remote status report for #385580
> #  * http://gcc.gnu.org/PR28146
> #  * remote status changed: (?) -> RESOLVED
> #  * remote resolution changed: (?) -> FIXED
> usertags 385580 + status-RESOLVED resolution-FIXED
Bug#385580: [4.1 regression, fixed in 4.2] gcc generates incorrect code on s390
There were no usertags set.
Usertags are now: resolution-FIXED status-RESOLVED.
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: [bts-link] source package gcc-4.0

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> #
> # bts-link upstream status pull for source package gcc-4.0
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> user [EMAIL PROTECTED]
Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]).
> # remote status report for #307207
> #  * http://gcc.gnu.org/PR19664
> #  * remote status changed: ASSIGNED -> RESOLVED
> #  * remote resolution changed: (?) -> FIXED
> #  * closed upstream
> tags 307207 + fixed-upstream
Bug#307207: [PR 22587] shared libraries built with -fvisibility=hidden segfaults
Tags were: upstream
Tags added: fixed-upstream

> usertags 307207 - status-ASSIGNED
Bug#307207: [PR 22587] shared libraries built with -fvisibility=hidden segfaults
Usertags were: status-ASSIGNED.
Usertags are now: .
> usertags 307207 + status-RESOLVED resolution-FIXED
Bug#307207: [PR 22587] shared libraries built with -fvisibility=hidden segfaults
There were no usertags set.
Usertags are now: resolution-FIXED status-RESOLVED.
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Processed: [bts-link] source package gcc-snapshot

[Debian Bug Tracking System]

Processing commands for [EMAIL PROTECTED]:

> #
> # bts-link upstream status pull for source package gcc-snapshot
> # see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
> #
> user [EMAIL PROTECTED]
Setting user to [EMAIL PROTECTED] (was [EMAIL PROTECTED]).
> # remote status report for #382950
> #  * http://gcc.gnu.org/PR24367
> #  * remote status changed: ASSIGNED -> RESOLVED
> #  * remote resolution changed: (?) -> FIXED
> #  * closed upstream
> tags 382950 + fixed-upstream
Bug#382950: [s390] in extract_insn, at recog.c:2077
Tags were: upstream
Tags added: fixed-upstream

> usertags 382950 - status-ASSIGNED
Bug#382950: [s390] in extract_insn, at recog.c:2077
Usertags were: status-ASSIGNED.
Usertags are now: .
> usertags 382950 + status-RESOLVED resolution-FIXED
Bug#382950: [s390] in extract_insn, at recog.c:2077
There were no usertags set.
Usertags are now: resolution-FIXED status-RESOLVED.
> # remote status report for #385182
> #  * http://gcc.gnu.org/PR28903
> #  * remote status changed: (?) -> NEW
> usertags 385182 + status-NEW
Bug#385182: c++: rejects VLA in template class's member with using
There were no usertags set.
Usertags are now: status-NEW.
> # remote status report for #385306
> #  * http://gcc.gnu.org/PR28899
> #  * remote status changed: (?) -> RESOLVED
> #  * remote resolution changed: (?) -> FIXED
> #  * closed upstream
> tags 385306 + fixed-upstream
Bug#385306: ICE: gimplification failed, c++
Tags were: upstream
Tags added: fixed-upstream

> usertags 385306 + status-RESOLVED resolution-FIXED
Bug#385306: ICE: gimplification failed, c++
There were no usertags set.
Usertags are now: resolution-FIXED status-RESOLVED.
> # remote status report for #385339
> #  * http://gcc.gnu.org/PR28905
> #  * remote status changed: (?) -> ASSIGNED
> usertags 385339 + status-ASSIGNED
Bug#385339: ICE in compare_name_with_value, at tree-vrp.c:3557
There were no usertags set.
Usertags are now: status-ASSIGNED.
> # remote status report for #385342
> #  * http://gcc.gnu.org/PR28906
> #  * remote status changed: (?) -> ASSIGNED
> usertags 385342 + status-ASSIGNED
Bug#385342: ICE: tree check: did not expect class 'type', have 'type' 
(template_type_parm) in contains_placeholder_p, at tree.c:2223
There were no usertags set.
Usertags are now: status-ASSIGNED.
> # remote status report for #383848
> #  * http://gcc.gnu.org/PR26197
> #  * remote status changed: NEW -> RESOLVED
> #  * remote resolution changed: (?) -> FIXED
> #  * closed upstream
> forwarded 383848 http://gcc.gnu.org/PR27474, merged-upstream: 
> http://gcc.gnu.org/PR26197
Bug#383848: ICE: tree check: expected ssa_name, have struct_field_tag in 
verify_ssa, at tree-ssa.c:776
Forwarded-to-address changed from http://gcc.gnu.org/PR27474 to 
http://gcc.gnu.org/PR27474, merged-upstream: http://gcc.gnu.org/PR26197.

> tags 383848 + fixed-upstream
Bug#383848: ICE: tree check: expected ssa_name, have struct_field_tag in 
verify_ssa, at tree-ssa.c:776
Tags were: upstream
Tags added: fixed-upstream

> usertags 383848 - status-NEW
Bug#383848: ICE: tree check: expected ssa_name, have struct_field_tag in 
verify_ssa, at tree-ssa.c:776
Usertags were: status-NEW.
Usertags are now: .
> usertags 383848 + status-RESOLVED resolution-FIXED
Bug#383848: ICE: tree check: expected ssa_name, have struct_field_tag in 
verify_ssa, at tree-ssa.c:776
There were no usertags set.
Usertags are now: resolution-FIXED status-RESOLVED.
> thanks
Stopping processing here.

Please contact me if you need assistance.

Debian bug tracking system administrator
(administrator, Debian Bugs database)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[bts-link] source package gcc-4.1

[bts-link-upstream]

#
# bts-link upstream status pull for source package gcc-4.1
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#

user [EMAIL PROTECTED]

# remote status report for #356548
#  * http://gcc.gnu.org/PR26670
#  * remote status changed: ASSIGNED -> RESOLVED
#  * remote resolution changed: (?) -> FIXED
#  * closed upstream
tags 356548 + fixed-upstream
usertags 356548 - status-ASSIGNED
usertags 356548 + status-RESOLVED resolution-FIXED

# remote status report for #385580
#  * http://gcc.gnu.org/PR28146
#  * remote status changed: (?) -> RESOLVED
#  * remote resolution changed: (?) -> FIXED
usertags 385580 + status-RESOLVED resolution-FIXED

thanks

[bts-link] source package gcc-4.0

[bts-link-upstream]

#
# bts-link upstream status pull for source package gcc-4.0
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#

user [EMAIL PROTECTED]

# remote status report for #307207
#  * http://gcc.gnu.org/PR19664
#  * remote status changed: ASSIGNED -> RESOLVED
#  * remote resolution changed: (?) -> FIXED
#  * closed upstream
tags 307207 + fixed-upstream
usertags 307207 - status-ASSIGNED
usertags 307207 + status-RESOLVED resolution-FIXED

thanks

[bts-link] source package gcc-snapshot

[bts-link-upstream]

#
# bts-link upstream status pull for source package gcc-snapshot
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#

user [EMAIL PROTECTED]

# remote status report for #382950
#  * http://gcc.gnu.org/PR24367
#  * remote status changed: ASSIGNED -> RESOLVED
#  * remote resolution changed: (?) -> FIXED
#  * closed upstream
tags 382950 + fixed-upstream
usertags 382950 - status-ASSIGNED
usertags 382950 + status-RESOLVED resolution-FIXED

# remote status report for #385182
#  * http://gcc.gnu.org/PR28903
#  * remote status changed: (?) -> NEW
usertags 385182 + status-NEW

# remote status report for #385306
#  * http://gcc.gnu.org/PR28899
#  * remote status changed: (?) -> RESOLVED
#  * remote resolution changed: (?) -> FIXED
#  * closed upstream
tags 385306 + fixed-upstream
usertags 385306 + status-RESOLVED resolution-FIXED

# remote status report for #385339
#  * http://gcc.gnu.org/PR28905
#  * remote status changed: (?) -> ASSIGNED
usertags 385339 + status-ASSIGNED

# remote status report for #385342
#  * http://gcc.gnu.org/PR28906
#  * remote status changed: (?) -> ASSIGNED
usertags 385342 + status-ASSIGNED

# remote status report for #383848
#  * http://gcc.gnu.org/PR26197
#  * remote status changed: NEW -> RESOLVED
#  * remote resolution changed: (?) -> FIXED
#  * closed upstream
forwarded 383848 http://gcc.gnu.org/PR27474, merged-upstream: 
http://gcc.gnu.org/PR26197
tags 383848 + fixed-upstream
usertags 383848 - status-NEW
usertags 383848 + status-RESOLVED resolution-FIXED

thanks

Bug#383251: g++-4.1: FTBFS for RQuantLib on i386/testing

[Dirk Eddelbuettel]

One interesting little illustration is provided by the CRAN timing
summaries. The master site of CRAN (the CTAN / CPAN equivalent for R) is
hosted on Debian testing.  Compile/build/test times are shown at
   http://cran.r-project.org/src/contrib/checkTimings.html
and RQuantLib is the 2nd most time-consuming packages -- right after RGtk2 
which happens to be around thirty (!!) times larger when we compare the
orig.tar.gz [ flawed, as we know that RGtk2 also has a lot of documentation ]
but still. 

[EMAIL PROTECTED]:/var/local/cache/pbuilder/result> ls -lh 
rgtk2_2.8.5.orig.tar.gz \
rquantlib_0.2.4.orig.tar.gz
-rw-r--r-- 1 edd edd 1.8M Jun 22 19:39 rgtk2_2.8.5.orig.tar.gz
-rw-r--r-- 1 edd edd  64K Aug 14 22:39 rquantlib_0.2.4.orig.tar.gz

Still compile/link with g++-4.1 sucks really big time for certain projects.

Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
  -- Thomas A. Edison


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

[Bug c++/27094] [4.0 Regression] tree check: expected tree_list, have omp_return in build_call

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

   What|Removed |Added

   Last reconfirmed|2006-04-10 11:34:47 |2006-09-03 21:35:44
   date||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27094

--- 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#341882: marked as done (gcc-4.0: [mips] support for tri-arch on mips & mipsel)

[Debian Bug Tracking System]

Your message dated Mon, 4 Sep 2006 02:50:12 +0200
with message-id <[EMAIL PROTECTED]>
and subject line Bug#341882: binutils fix
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--- Begin Message ---
Package: gcc-4.0
Version: 4.0.2-4.1
Severity: wishlist
Tags: patch


Please enable tri-arch support for the MIPS platforms. The attached
patch (and a corresponding patch to glibc) provide support for n32 & n64
ABIs in addition to the current o32 ABI. These patches have been tested
by building n32 & n64 version of the ltp packages.

-- System Information:
Debian Release: testing/unstable
  APT prefers testing
  APT policy: (600, 'testing')
Architecture: mipsel (mips64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14-rc1-Helix64-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages gcc-4.0 depends on:
ii  binutils 2.16.1-2The GNU assembler, linker and bina
ii  cpp-4.0  4.0.2-4.1   The GNU C preprocessor
ii  gcc-4.0-base 4.0.2-4.1   The GNU Compiler Collection (base 
ii  libc62.3.5-8.2   GNU C Library: Shared libraries an
ii  libgcc1  1:4.0.2-4.1 GCC support library

Versions of packages gcc-4.0 recommends:
ii  libc6-dev 2.3.5-8.2  GNU C Library: Development Librari
ii  libmudflap0-dev   4.0.2-4.1  GCC mudflap support libraries (dev

-- no debconf information
Index: debian/rules.patch
===
--- debian/rules.patch  (.../vendor/gcc-4.0/current)(revision 145)
+++ debian/rules.patch  (.../src/gcc-4.0)   (revision 145)
@@ -102,6 +102,7 @@
 endif
 ifneq (,$(findstring /$(DEB_TARGET_ARCH)/,/mips/mipsel/))
   debian_patches += libffi-mips libmudflap-entry-point libmudflap-mips
+  debian_patches += mips-biarch
 endif
 
 ifeq ($(DEB_TARGET_ARCH_OS),kfreebsd)
Index: debian/patches/mips-biarch.dpatch
===
--- debian/patches/mips-biarch.dpatch   (.../vendor/gcc-4.0/current)
(revision 0)
+++ debian/patches/mips-biarch.dpatch   (.../src/gcc-4.0)   (revision 145)
@@ -0,0 +1,85 @@
+#! /bin/sh -e
+
+# DP: Patch author: Stuart Anderson <[EMAIL PROTECTED]>
+# DP: Upstream status: Not submitted
+# DP: Description: add full tri-arch support. Include linux64.h also fix up
+# DP: Description: the directory names so that o32 is the default and follow
+# DP: Description: the glibc convention for 32 & 64 bit names
+
+dir=
+if [ $# -eq 3 -a "$2" = '-d' ]; then
+pdir="-d $3"
+dir="$3/"
+elif [ $# -ne 1 ]; then
+echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
+exit 1
+fi
+case "$1" in
+-patch)
+patch $pdir -c -f --no-backup-if-mismatch -p1 < $0
+;;
+-unpatch)
+patch $pdir -c -f --no-backup-if-mismatch -R -p1 < $0
+;;
+*)
+echo >&2 "`basename $0`: script expects -patch|-unpatch as argument"
+exit 1
+esac
+exit 0
+
+*** src/gcc/config.gcc.bak Mon Oct  3 16:12:53 2005
+--- src/gcc/config.gcc Mon Oct  3 16:19:45 2005
+***
+*** 1424,1430 
+   gas=yes
+   ;;
+  mips*-*-linux*)  # Linux MIPS, either endian.
+! tm_file="dbxelf.h elfos.h svr4.h linux.h ${tm_file} mips/linux.h"
+   case ${target} in
+  mipsisa32*-*)
+  target_cpu_default="MASK_SOFT_FLOAT"
+--- 1424,1431 
+   gas=yes
+   ;;
+  mips*-*-linux*)  # Linux MIPS, either endian.
+! tm_file="dbxelf.h elfos.h svr4.h linux.h ${tm_file} mips/linux.h 
mips/linux64.h"
+!  tmake_file="${tmake_file} mips/t-linux64"
+   case ${target} in
+  mipsisa32*-*)
+  target_cpu_default="MASK_SOFT_FLOAT"
+
+*** src/gcc/config/mips/linux64.h.bak  Mon Oct  3 11:28:01 2005
+--- src/gcc/config/mips/linux64.h  Mon Oct  3 11:28:29 2005
+***
+*** 23,29 
+ in order to make the other specs easier to write.  */
+  #define DRIVER_SELF_SPECS \
+  "%{!EB:%{!EL:%(endian_spec)}}", \
+! "%{!mabi=*: -mabi=n32}"
+  
+  #undef SUBTARGET_ASM_SPEC
+  #define SUBTARGET_ASM_SPEC "\
+--- 23,29 
+ in order to make the other specs easier to write.  */
+  #define DRIVER_SELF_SPECS \
+  "%{!EB:%{!EL:%(endian_spec)}}", \
+! "%{!mabi=*: -mabi=32}"
+  
+  #undef SUBTARGET_ASM_SPEC
+  #define SUBTARGET_ASM_SPEC "\
+
+*** src/gcc/config/mips/t-linux64.orig Wed Oct 19 06:19:32 2005
+--- src/gcc/co

Bug#341882: marked as done (gcc-4.0: [mips] support for tri-arch on mips & mipsel)

[Aurelien Jarno]

Sujet:
Re: Bug#341882: binutils fix
Expéditeur:
Matthias Klose <[EMAIL PROTECTED]>
Date:
Mon, 4 Sep 2006 02:50:12 +0200
Destinataire:
Stuart Anderson <[EMAIL PROTECTED]>, [EMAIL PROTECTED]

Destinataire:
Stuart Anderson <[EMAIL PROTECTED]>, [EMAIL PROTECTED]
Copie à:
[EMAIL PROTECTED]


tags 341882 + wontfix
thanks

Now really closing the report.  Stuart, please see the bug log, how to
forward-port the patch to 4.1.



For your information, I am already working on that, but I am lacking a 
bit of time. I currently have clean glibc 2.4 packages (with NPTL 
support for all three ABIs), and ugly gcc-4.1 packages. I will try to 
make the gcc patches clean asap. Anyway, I think it will be for etch + 1 
as the glibc is frozen.


--
  .''`.  Aurelien Jarno | GPG: 1024D/F1BCDB73
 : :' :  Debian developer   | Electrical Engineer
 `. `'   [EMAIL PROTECTED] | [EMAIL PROTECTED]
   `-people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]