Compiler error in necpp

Sascha 'saigkill' Manns

15 Nov 2009 15 Nov '09

19:24

Hallo Leute, beim kompilieren des neuen necpp stoße ich auf einen Error: libtool: compile: g++ -DHAVE_CONFIG_H -I. -I.. -fmessage-length=0 -O2 - Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables - fasynchronous-unwind-tables -MT libnecpp_la-c_geometry.lo -MD -MP -MF .deps/libnecpp_la-c_geometry.Tpo -c c_geometry.cpp -fPIC -DPIC -o .libs/libnecpp_la-c_geometry.o c_geometry.cpp: In member function 'void c_geometry::geometry_complete(nec_context*, int, int)': c_geometry.cpp:505: error: 'uint32_t' was not declared in this scope c_geometry.cpp:505: error: expected ';' before 'i' c_geometry.cpp:505: error: 'i' was not declared in this scope c_geometry.cpp:508: error: expected ';' before 'j' c_geometry.cpp:508: error: 'j' was not declared in this scope Der Übersicht halber habe ich die betreffede Zeile in Pastebin gepostet: http://pastebin.ca/1672443. Hat jemand ne Idee? -- Sincerely yours Sascha Manns openSUSE Member openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://saigkill.wordpress.com ClaimID: http://claimid.com/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

Show replies by date

David Haller

15 Nov 15 Nov

21:20

Hallo, Am Son, 15 Nov 2009, Sascha 'saigkill' Manns schrieb:

...

c_geometry.cpp: In member function 'void c_geometry::geometry_complete(nec_context*, int, int)': c_geometry.cpp:505: error: 'uint32_t' was not declared in this scope [..] Hat jemand ne Idee?

#include <cstdint> oben bei den includes ergänzen. Wendest du eigentlich den debian-patch an? Und sind das die Debian-Quellen necpp_1.4.0+cvs20091005.orig.tar.gz? -dnh -- Es ist nicht schön, wenn man am Kernel schrauben _muß_, es ist aber sehr nützlich, wenn man es _kann_. -- Falk Willberg -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

Sascha 'saigkill' Manns

21:39

Servus David, Am Sonntag 15 November 2009 22:20:49 wrote David Haller:

...

Hallo,

Am Son, 15 Nov 2009, Sascha 'saigkill' Manns schrieb:

...
c_geometry.cpp: In member function 'void c_geometry::geometry_complete(nec_context*, int, int)': c_geometry.cpp:505: error: 'uint32_t' was not declared in this scope

[..]

...
Hat jemand ne Idee?

#include <cstdint> Woher weißt du sowas immer?

...

oben bei den includes ergänzen. Wendest du eigentlich den debian-patch an? Welchen meinst du?

...

Und sind das die Debian-Quellen necpp_1.4.0+cvs20091005.orig.tar.gz? Ja, ich habe die Sourcen neu gepackt als tar.bz2 ohne orig.

Jetzt will er meinen Patch nicht- Erstellt mit: quilt new necpp-compiler_errors.patch und quilt refresh - p0 necpp-compiler_errors.patch. Anschließend ins Spec eingebaut: Patch4: %{name}-compiler_errors.patch %patch4 -p0 Der Patch (anbei) müsste doch konform sein... -- Sincerely yours Sascha Manns openSUSE Member openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://saigkill.wordpress.com ClaimID: http://claimid.com/saigkill

David Haller

22:53

Hallo, Am Son, 15 Nov 2009, Sascha 'saigkill' Manns schrieb:

...

Am Sonntag 15 November 2009 22:20:49 wrote David Haller:

...
Am Son, 15 Nov 2009, Sascha 'saigkill' Manns schrieb:

...
c_geometry.cpp: In member function 'void c_geometry::geometry_complete(nec_context*, int, int)': c_geometry.cpp:505: error: 'uint32_t' was not declared in this scope Hat jemand ne Idee?

#include <cstdint> Woher weißt du sowas immer?

Erfahrung / gutes Raten ;) Fehler == unbekannter (hier) Typ -> grep wo der definiert ist -> #include -> bei C++ und libc-Headern wie stdint.h dann per #include einbinden

...

...
oben bei den includes ergänzen. Wendest du eigentlich den debian-patch an? Welchen meinst du?

necpp_1.4.0+cvs20091005-1.diff.gz aus dem gleichen Verzeichnis wie die Quellen.

...

...
Und sind das die Debian-Quellen necpp_1.4.0+cvs20091005.orig.tar.gz? Ja, ich habe die Sourcen neu gepackt als tar.bz2 ohne orig.

Jetzt will er meinen Patch nicht-

Erstellt mit: quilt new necpp-compiler_errors.patch und quilt refresh - p0 necpp-compiler_errors.patch. [..] Der Patch (anbei) müsste doch konform sein...

Seltsam. Der Patch schaut ok aus. Und läßt sich hier auch problemlos auch mit --fuzz=0 einspielen. Ändert evtl. einer der vorhergehenden Patches was an der Datei? der Debian-patch fügt IIRC noch <cstdlib> ein. Ah. Gefunden. necpp-g++.patch ist die Ursache (und sowieso überarbeitungswürdig): ==== diff -uNrp necpp-1.3.0+cvs20090101/src/c_geometry.cpp necpp-1.3.0+cvs20090101p/src/c_geometry.cpp --- necpp-1.3.0+cvs20090101/src/c_geometry.cpp 2008-12-14 22:43:41.000000000 +0100 +++ necpp-1.3.0+cvs20090101p/src/c_geometry.cpp 2009-04-12 19:44:25.000000000 +0200 @@ -17,10 +17,10 @@ Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include "c_geometry.h" - +#include <cstdlib> #include "nec_context.h" #include "nec_exception.h" - +#include #include <cstring> c_geometry::c_geometry() ==== stdlib.h == cstdlib stdarg.h == cstdarg string.h == cstring Am besten laß den ganzen Patch weg. Ich häng dir mal Ersatz an. (mit -p1 einzuspielen) HTH, -dnh -- Er will sie nicht? Er, will sie nicht? Er will, sie nicht? Er will sie, nicht? -- Sascha Broich

Sascha 'saigkill' Manns

16 Nov 16 Nov

14:07

Moin David, Am Sonntag 15 November 2009 23:53:46 wrote David Haller:

...

Hallo,

Am Son, 15 Nov 2009, Sascha 'saigkill' Manns schrieb:

...
Am Sonntag 15 November 2009 22:20:49 wrote David Haller:

...
Am Son, 15 Nov 2009, Sascha 'saigkill' Manns schrieb:

...
c_geometry.cpp: In member function 'void c_geometry::geometry_complete(nec_context*, int, int)': c_geometry.cpp:505: error: 'uint32_t' was not declared in this scope Hat jemand ne Idee?

#include <cstdint>

Woher weißt du sowas immer?

Erfahrung / gutes Raten ;)

Fehler == unbekannter (hier) Typ -> grep wo der definiert ist -> #include -> bei C++ und libc-Headern wie stdint.h dann per #include einbinden hoffentlich schaffe ich das auch mal :-)

...

...
...
oben bei den includes ergänzen. Wendest du eigentlich den debian-patch an?

Welchen meinst du?

necpp_1.4.0+cvs20091005-1.diff.gz

aus dem gleichen Verzeichnis wie die Quellen. Bisher habe ich ihn nicht angewendet. Allerdings scheint es derselbe zu sein, den du freuindlicherweise erstellt hast.

...

ein. Ah. Gefunden. necpp-g++.patch ist die Ursache (und sowieso überarbeitungswürdig): Stimmt ja. Wenn ein Patch vorher die Datei anfasste kann es auch nen Fehler geben.

Sacht dir das zufällig auch was? In file included from /usr/include/c++/4.4/cstdint:35, from c_geometry.cpp:20: /usr/include/c++/4.4/c++0x_warning.h:31:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options. c_geometry.cpp: In member function 'void c_geometry::wire(int, int, nec_float, nec_float, nec_float, nec_float, nec_float, nec_float, nec_float, nec_float, nec_float)': c_geometry.cpp:712: warning: 'delz' may be used uninitialized in this function make[2]: *** [libnecpp_la-c_geometry.lo] Error 1 -- Sincerely yours Sascha Manns openSUSE Member openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://saigkill.wordpress.com ClaimID: http://claimid.com/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

Philipp Thomas

19:28

On Mon, 16 Nov 2009 15:07:03 +0100, you wrote:

...

hoffentlich schaffe ich das auch mal :-)

Dann solltest lernen, in C und C++ programmieren zu können. Nur mit dem Wissen kann man solche Fehler sicher beheben.

...

c_geometry.cpp:712: warning: 'delz' may be used uninitialized in this

Das sagt der Compiler, wenn im Code nicht direkt zu erkennen ist, ob die betreffende Variable initialisiert wird bevor sie genutzt wird. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

Sascha 'saigkill' Manns

20:04

Servus,

...

...
c_geometry.cpp:712: warning: 'delz' may be used uninitialized in this

Das sagt der Compiler, wenn im Code nicht direkt zu erkennen ist, ob die betreffende Variable initialisiert wird bevor sie genutzt wird. Wie kann ich delz initialisieren? #include <delz>?

-- Sincerely yours Sascha Manns openSUSE Member openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://saigkill.wordpress.com ClaimID: http://claimid.com/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

Manfred Hollstein

21:06

Moin, On Mon, 16 Nov 2009, 21:04:40 +0100, Sascha 'saigkill' Manns wrote:

...

Servus,

...
...
c_geometry.cpp:712: warning: 'delz' may be used uninitialized in this

Das sagt der Compiler, wenn im Code nicht direkt zu erkennen ist, ob die betreffende Variable initialisiert wird bevor sie genutzt wird. Wie kann ich delz initialisieren? #include <delz>?

Ist die Frage wirklich ernst gemeint? Ich schlage echt vor, dass du dir bei solchen Themen tatsaechlich mal ein entsprechendes Buch kaufst... Schlagzeilen der Art "New exploit found for security issue xyz in abc" ruehren tatsaechlich auch von solchen Problemen her. Wenn delz z.B. vom Typ "int" ist, dann sollte eine Initialisierung der Art: int delz = -1; helfen, damit z.B. in solchen Code-Sequenzen kein Muell passiert: for (i = 0; i <= delz; ++i) buf[i] = foobar[delz + i]; Wenn hier naemlich delz nicht initialisiert waere, dann ist's davon abhaengig, was hier an der aktuellen Position im Stack steht, an dem "delz" in der aktuellen Funktion angelegt ist, und damit, wie lange die Schleife tatsaechlich laeuft - und damit, welche Speicherbereiche damit ueberschrieben wuerden... Sorry, aber Fehler sollte man nur versuchen zu korrigieren, wenn man auch wirklich versteht, was man da tut. Cheers. l8er manfred -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

David Haller

21:48

Hallo, Am Mon, 16 Nov 2009, Manfred Hollstein schrieb: [..]

...

helfen, damit z.B. in solchen Code-Sequenzen kein Muell passiert:

for (i = 0; i <= delz; ++i) buf[i] = foobar[delz + i];

Schlechtes Beispiel. Vorführeffekt. Hier wird i ja initialisiert. -dnh -- For every complex problem, there is a solution that is simple, neat, and wrong. -- H. L. Mencken -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

Thomas Hertweck

23:42

David Haller wrote:

...

Am Mon, 16 Nov 2009, Manfred Hollstein schrieb: [..]

...
helfen, damit z.B. in solchen Code-Sequenzen kein Muell passiert:

for (i = 0; i <= delz; ++i) buf[i] = foobar[delz + i];

Schlechtes Beispiel. Vorführeffekt. Hier wird i ja initialisiert.

delz ist aber im Prinzip uninitialisiert, wenn ich die Email richtig verstanden habe... Das Beispiel ist trotzdem vielleicht relativ ungeschickt, weil der Compiler hier eindeutig erkennen kann, dass delz nicht initialisiert ist (sofern die Deklaration von delz im selben Code-Abschnitt erfolgt), es fuehrt also zu einer "warning: 'delz' is used uninitialized in this function" Warnung, nicht zu einer "may be used uninitialized" Meldung. Ich nehme aber an, das alles war eh nur zur Illustration und nicht als wortwoertliches Beispiel gedacht, insofern hat Manfred schon recht. Im GCC Manual hat es wie gesagt relevante Beispiele, die verschiedene Faelle zeigen, wann bzw. wann nicht eine Variable als uninitialisiert durch den Compiler erkannt wird. Cheers, Thomson -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

Sascha 'saigkill' Manns

17 Nov 17 Nov

16:47

Hallo Manfred, Am Montag 16 November 2009 22:06:08 wrote Manfred Hollstein:

...

Ist die Frage wirklich ernst gemeint? Ich schlage echt vor, dass du dir bei solchen Themen tatsaechlich mal ein entsprechendes Buch kaufst... vielen Dank für deine Kritik, und ja du hast Recht. Ein Buch werde ich mir noch besorgen. Aber ich denke, wenn ich ein Jahr zurückblicke, dass ich bereits vieles gelernt habe. Und dass man ruhig die Tatsache würdigen kann, dass man sich in seiner Freizeit hinsetzt und Pakete baut. ;-) In den letzten Malen waren es auch nur kleinigkeiten gewesen, und ebenso schnell konnte das Problem behoben werden. Jeder in dieser Liste hat mal klein angefangen, und hat sich hochgearbeitet. Nur mal so am Rande ;-) -- Sincerely yours

Sascha Manns openSUSE Member openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://saigkill.wordpress.com ClaimID: http://claimid.com/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

Thomas Hertweck

16 Nov 16 Nov

21:56

Sascha 'saigkill' Manns wrote:

...

...
...
c_geometry.cpp:712: warning: 'delz' may be used uninitialized

Das sagt der Compiler, wenn im Code nicht direkt zu erkennen ist, ob die betreffende Variable initialisiert wird bevor sie genutzt wird.

Wie kann ich delz initialisieren? #include <delz>?

Uh, vielleicht solltest Du doch einmal etwas Programmieren lernen. Nichts fuer ungut und Dein Engagement in allen Ehren, ich bekomme allerdings immer Bauchweh, wenn ich solche Fragen von Leuten sehe, die ganz offiziell Pakete fuer openSUSE via Buildservice bauen. delz ist eine Variable im Code. Die Variable wird an einer Stelle im Code benutzt und der Compiler kann nicht genau erkennen, ob dieser Variablen vorher ein Wert zugewiesen wurde. Falls das nicht geschah bis zu dem Zeitpunk der Verwendung der Variablen ist diese Variable offensichtlich uninitialisiert und liefert (das ist aber compilerabhaengig) i.d.R. eine Zufallszahl - Zufallszahl heisst hier, Du bekommst schlicht das, was zufaelligerweise gerade an der Speicheradresse der uninitialisierten Variablen steht. Du bekommst nicht das, was der Programmierer urspruenglich mal angedacht hat. Je nachdem, was auf die Benutzung der uninitialisierten Variablen folgt, kann das Programm abstuerzen, falsche Ergebnisse liefern, oder auch zufaelligerweise richtige Ergebnisse liefern oder Ergebnisse, die zumindest plausibel aussehen. Tools wie valgrind checken jeden Speicherzugriff zur Laufzeit und entdecken relativ leicht uninitialisierte Variablen. Allerdings erhoeht sich die Laufzeit des Programms drastisch. Fuer Entwicklung und Debuggen von Programmen ist valgrind (oder insure++ etc) aber IMO unverzichtbar. Der Compiler kann manchmal schon beim Compilieren entdecken, ob eine Variable uninitialisiert ist. Oftmals aber nicht mit absoluter Sicherheit. Deswegen heisst es "may be used uninitialized" (falls der Compiler sicher ist, heisst es "is used uninitialized"). Das Problem tritt z.B. auf, wenn eine Variable unter Bedingungen (d.h. in einem if-statement) initialisiert wird. Das muss nicht zwangsweise xur Folge haben, dass die Variable spaeter uninitialisiert verwendet wird (der Programmierer mag wissen, ob das der Fall ist oder nicht), aber es besteht die Moeglichkeit. Siehe das gcc Manual fuer Beispiele, suche nach -Wuninitialized. In anderen Worten, die Warnung des Compilers kann muss aber nicht auf einen Bug hindeuten. Um auf Dein Problem zurueckzukommen: Man kann die Warnung abstellen, in dem man delz schon bei der Deklaration einen Wert zuweist. Allerdings muss man den Code und das Problem verstehen, um Variablen korrekt zu initialisieren, nicht immer ist Initialisieren mit 0 oder 0.0 korrekt. Wenn man Bugs finden will, hilft es manchmal auch, alle Variablen mit sehr seltsamen Werten zu initialisieren, da es die Wahrscheinlichkeit von Problemen zur Laufzeit erhoeht und man so einfacher Bugs finden kann. Manche Compiler (wie z.B. der von Intel) koennen das automatisch erledigen (zumindest in Fortran, bei C/C++ weiss ich das gerade nicht). Hope this helps, Thomson -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

David Haller

20:50

Hallo, Am Mon, 16 Nov 2009, Sascha 'saigkill' Manns schrieb:

...

Am Sonntag 15 November 2009 23:53:46 wrote David Haller:

...
Fehler == unbekannter (hier) Typ -> grep wo der definiert ist -> #include -> bei C++ und libc-Headern wie stdint.h dann per #include einbinden hoffentlich schaffe ich das auch mal :-)

C Grundlagen braucht's halt. Mir hat der K&R (Kernighan & Ritchie, The C Programming Language) sehr geholfen, bei C++ hab ich den Stroustrup. Es gibt auch online einiges Material.

...

...
...
...
oben bei den includes ergänzen. Wendest du eigentlich den debian-patch an?

Welchen meinst du?

necpp_1.4.0+cvs20091005-1.diff.gz

aus dem gleichen Verzeichnis wie die Quellen. Bisher habe ich ihn nicht angewendet. Allerdings scheint es derselbe zu sein, den du freuindlicherweise erstellt hast.

Nein. Der patcht noch einiges anderes. Hab jetzt nicht geschaut, ob der sich mit meinem veträgt. Im Zweifelsfall mußt du halt meinen neu erstellen.

...

...
ein. Ah. Gefunden. necpp-g++.patch ist die Ursache (und sowieso überarbeitungswürdig): Stimmt ja. Wenn ein Patch vorher die Datei anfasste kann es auch nen Fehler geben.

Genau. Durch die zusätzliche #include-Zeile passte es nimmer.

...

Sacht dir das zufällig auch was? In file included from /usr/include/c++/4.4/cstdint:35, from c_geometry.cpp:20: /usr/include/c++/4.4/c++0x_warning.h:31:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.

Ergänze die CXXFLAGS vor'm configure: CXXFLAGS="%{optflags} -std=gnu++0x" (oder wie du sonst halt die CXXFLAGS setzt)

...

c_geometry.cpp:712: warning: 'delz' may be used uninitialized in this function

Die Warnung kannst du IMO dagegen ignorieren. Allen 'unitialized' nachzugehen würde oft sehr lange dauern. -dnh -- We deal in the moral equivalent of black holes, where the normal laws of right and wrong break down; beyond those metaphysical event horizons there exist ... special circumstances -- Use Of Weapons -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

Philipp Thomas

17 Nov 17 Nov

02:28

On Mon, 16 Nov 2009 21:50:33 +0100, you wrote:

...

C Grundlagen braucht's halt. Mir hat der K&R (Kernighan & Ritchie, The C Programming Language) sehr geholfen

Den sollte man aber heutzutage nicht mehr nehmen, es sei denn es gibt eine dem aktuellen C-Standard angepasste Version.

...

bei C++ hab ich den Stroustrup.

Auch da tendiere ich eher dagegen. Stroustrup ist IMO nicht immer sehr verständlich.

...

Die Warnung kannst du IMO dagegen ignorieren. Allen 'unitialized' nachzugehen würde oft sehr lange dauern.

Kann aber sehr lohnend sein, schon um die Warnungen weg zu haben. Meine Devise heisst "sollte mit -Werror" sauber bauen, zumindest solange es die verfügbare Zeit erlaubt. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

David Haller

03:06

Hallo, Am Die, 17 Nov 2009, Philipp Thomas schrieb:

...

On Mon, 16 Nov 2009 21:50:33 +0100, you wrote:

...
C Grundlagen braucht's halt. Mir hat der K&R (Kernighan & Ritchie, The C Programming Language) sehr geholfen

Den sollte man aber heutzutage nicht mehr nehmen, es sei denn es gibt eine dem aktuellen C-Standard angepasste Version.

Ich hab hier die 2nd Ed. von '88, die Unterschiede zu C99 sind nicht soo groß bzw. die schafft man sich schnell drauf, wenn man die Grundlagen mal kapiert hat ;) Ich verzweifel eher am wilden Code anderer ... Oder an den Buildsystemen.

...

...
bei C++ hab ich den Stroustrup.

Auch da tendiere ich eher dagegen. Stroustrup ist IMO nicht immer sehr verständlich.

Ich find ihn gut verständlich :) Achso: beide auf englisch. Keine Ahnung, wie die Übersetzungen sind.

...

...
Die Warnung kannst du IMO dagegen ignorieren. Allen 'unitialized' nachzugehen würde oft sehr lange dauern.

Kann aber sehr lohnend sein, schon um die Warnungen weg zu haben.

Ack.

...

Meine Devise heisst "sollte mit -Werror" sauber bauen, zumindest solange es die verfügbare Zeit erlaubt.

Ja. Aber bei teils hunderten Warnungen will man sich nicht immer durchwühlen, v.a. wenn man nur "mal eben" ein Paket backen will. Da nehm ich eben auch mal "tarball as is" und bastel nur an den Errors rum ... Mein eigenes Zeug kompiliert mind. mit -Wall -W -Werror durch, Ausnahmen gibt's nur wenn der Fehler aus nem Fremdheader kommt. Aber ich schreib ja auch praktisch nix. Am geilsten find ich immer die Pakete, die im configure, womöglich noch per default, ein '--enable-warnings', das u.U. sogar ein -Werror oder -pedantic enthält, und die noch nichtmal mit nem simplen '-Wall' durchkompilieren ... (und das auch unter der 11.1). -dnh -- "[the block drivers and the buffer cache] aren't incestuous, they're just living in sin.. " -- Linus Torvalds -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

Philipp Thomas

05:23

On Tue, 17 Nov 2009 04:06:11 +0100, you wrote:

...

nehm ich eben auch mal "tarball as is" und bastel nur an den Errors rum ...

Aber z.B. Off-by-one Fehler (meist wenn Leute vergessen, dass array[Anzahl] einer zuviel ist :) sind nur Warnungen. Also sollte man schon zusehen, welche Warnungen man bekommt. Und wenn Du dann einen Berg von eventuell uninitialisierten Variablen und ungenutzten lokalen Variablen hast wird es schwer, die wichtigen Warnungen zu sehen. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

Sascha 'saigkill' Manns

15 Nov 15 Nov

21:40

Achso, die Meldung lautete: Patch #4 (necpp-compiler_errors.patch): + /bin/cat /usr/src/packages/SOURCES/necpp-compiler_errors.patch + /usr/bin/patch -s -p0 --fuzz=0 1 out of 1 hunk FAILED -- saving rejects to file src/c_geometry.cpp.rej error: Bad exit status from /var/tmp/rpm-tmp.w39k65 (%prep) -- Sincerely yours Sascha Manns openSUSE Member openSUSE Ambassador openSUSE Marketing Team openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://saigkill.wordpress.com ClaimID: http://claimid.com/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org

5280

Age (days ago)

5282

Last active (days ago)

List overview

Download

16 comments

5 participants

participants (5)

David Haller
Manfred Hollstein
Philipp Thomas
Sascha 'saigkill' Manns
Thomas Hertweck