[Bug rtl-optimization/29329] [4.1 regression] internal consistency failure
-- fang at csl dot cornell dot edu changed: What|Removed |Added CC||fang at csl dot cornell dot ||edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29329 --- 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#407170: incompatibility between gfortran and gtkmm in debian testing
Package: gfortran
Version: 4:4.1.1-15
Package: libgtkmm-2.4-dev
Version: 1:2.8.8-1
The 3 files of test case I send you give a " Internal Error: printf is
broken"
When : always on debian testing. (works fine on gentoo with gtkmm 2.8.3
and gfortran 4.1.1-r1)
It works normally if you comment out "Gtk::Main kit(argc, argv);" in
principal.cc
I don't know if it is a gfortran problem, a gtkmm problem, or a debian
packaging problem.
Eric
#include
extern "C" {
void sub_();
}
int main(int argc, char *argv[])
{
Gtk::Main kit(argc, argv);
// Gtk::Window window;
// Gtk::Main::run(window); //Shows the window and returns when it is
closed.
sub_();
return 0;
}
SUBROUTINE sub()
implicit none
double precision a,b,c
a=100.1
b=200.2
c=(a+b)/2
write(*,*) "value=",a,b,c
end
ENDall: $(OBJETS)
gfortran sub.f -c
g++ principal.cc -O2 *.o -lgfortran `pkg-config gtkmm-2.4 --libs
--cflags` -o test
clean:
rm -f *.o
Re: Please allow gcc-doc-defaults 4.1.1.nf3 into etch
On Mon, Dec 18, 2006 at 03:19:16PM +0300, Nikita V. Youshchenko wrote: > > On Sat, Dec 16, 2006 at 03:37:48PM +0300, Nikita V. Youshchenko wrote: > > > > - If you have a package that needs updating, *please* don't forget > > > > to contact us. *Don't expect us to find out about it on our own*. > > > Please allow gcc-doc-defaults 4.1.1.nf3 into etch. > > > This upload fixes RC bug (#403328); the only change from previous > > > version is addition of missing Conflicts: entry. > > I don't understand why this is listed as a Conflicts:, instead of as a > > Conflicts: + Replaces:. Matthias, could you please comment? > Frankly saying, I still don't understand the details of 'Conflicts+Replaces > vs Conflicts' issue. Reading policy 7.5 and around doesn't help much. > Is 'Conflicts+Replaces' more correct in this case? Why? The 'Replaces' affects how the packaging tools decide which package should take precedence in the case of a conflict. > I'm ready to upload version with 'Conflicts+Replaces' at any moment if > needed. I think that would still be best. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
