Hallo Freunde, momentan baue ich libdbus++, aber make bricht ab bei: g++ -DHAVE_CONFIG_H -I. -I../../src -march=i586 -mtune=i686 -fmessage- length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -Wall -Werror -Wctor-dtor-privacy -Wnon- virtual-dtor -Woverloaded-virtual -Wno-deprecated -Wunused-parameter - Wunused-variable -Wunused-value -Wunused-function - I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -I../../include - march=i586 -mtune=i686 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -MT tinyxmlparser.lo -MD -MP -MF .deps/tinyxmlparser.Tpo -c .../tinyxmlparser.cpp -fPIC -DPIC -o .libs/tinyxmlparser.o cc1plus: warnings being treated as errors .../tinyxmlparser.cpp: In static member function 'static const char* TiXmlBase::SkipWhiteSpace(const char*, TiXmlEncoding)': .../tinyxmlparser.cpp:357: error: suggest parentheses around && within || make[3]: *** [tinyxmlparser.lo] Error 1 Was fehlt mir da? -- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hello, On Sun, 15 Feb 2009, Sascha 'saigkill' Manns wrote:
Hallo Freunde,
momentan baue ich libdbus++, aber make bricht ab bei:
g++ [..] -Werror [..] cc1plus: warnings being treated as errors
Hier steht's.
.../tinyxmlparser.cpp: In static member function 'static const char* TiXmlBase::SkipWhiteSpace(const char*, TiXmlEncoding)': .../tinyxmlparser.cpp:357: error: suggest parentheses around && within || make[3]: *** [tinyxmlparser.lo] Error 1
Was fehlt mir da?
Nix. Du hast ein '-Werror' zuviel in den CFLAGS. Guck mal bei den configure-Optionen, das wird gerne per '--enable-maintainer-mode' oder eine extra Option (z.B. --enable-werror) angefügt. HTH, -dnh -- Seely: Vielleicht schicken die ja nächstes Mal einen Mann für einen Männerjob ... Jordan: Was machen Sie dann hier? -- Crossing Jordan -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Sonntag 15 Februar 2009 21:56:31 David Haller wrote:
Hello,
On Sun, 15 Feb 2009, Sascha 'saigkill' Manns wrote:
Hallo Freunde,
momentan baue ich libdbus++, aber make bricht ab bei:
g++ [..] -Werror [..] cc1plus: warnings being treated as errors
Hier steht's.
.../tinyxmlparser.cpp: In static member function 'static const char* TiXmlBase::SkipWhiteSpace(const char*, TiXmlEncoding)': .../tinyxmlparser.cpp:357: error: suggest parentheses around && within || make[3]: *** [tinyxmlparser.lo] Error 1
Was fehlt mir da?
Nix. Du hast ein '-Werror' zuviel in den CFLAGS. Guck mal bei den configure-Optionen, das wird gerne per '--enable-maintainer-mode' oder eine extra Option (z.B. --enable-werror) angefügt. Was es alles für Fehler gibt. Vielen Dank für die mithilfe...
-- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Sonntag 15 Februar 2009 22:04:01 Sascha 'saigkill' Manns wrote:
g++ [..] -Werror [..] cc1plus: warnings being treated as errors
Hier steht's. Mal ne dumme Frage: Wie finde ich exakt die Zeile, die ich suche? Ich grase gerade die aclocal.m4 ab, aber die ist 1000de von Zeilen lang. Und ich weiß nicht woran ich mich orientieren kann.
-- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Sonntag 15 Februar 2009 21:56:31 David Haller wrote:
Hello,
On Sun, 15 Feb 2009, Sascha 'saigkill' Manns wrote:
Hallo Freunde,
momentan baue ich libdbus++, aber make bricht ab bei:
g++ [..] -Werror [..] cc1plus: warnings being treated as errors
Hier steht's.
.../tinyxmlparser.cpp: In static member function 'static const char* TiXmlBase::SkipWhiteSpace(const char*, TiXmlEncoding)': .../tinyxmlparser.cpp:357: error: suggest parentheses around && within || make[3]: *** [tinyxmlparser.lo] Error 1
Was fehlt mir da?
Nix. Du hast ein '-Werror' zuviel in den CFLAGS. Guck mal bei den configure-Optionen, das wird gerne per '--enable-maintainer-mode' oder eine extra Option (z.B. --enable-werror) angefügt. Also ich habe es rekonstruiert. Make war im Verzeichnis src/release. So bin ich in das Verzeichnis gegangen und dann im Makefile geschaut. Die Meldung beinhaltete "tinyxmlparser.cpp". Im Makefile gab es auch diesen Abschnitt mit "tinyxmlparser.cpp". Er lautete: @am__fastdepCXX_TRUE@ $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -MT tinyxmlparser.lo -MD -MP -MF $(DEPDIR)/tinyxmlparser.Tpo -c -o tinyxmlparser.lo `test -f '../tinyxmlparser.cpp' || echo '$(srcdir)/'`../tinyxmlparser.cpp
Ist das der richtige Abschnitt? Wo kann ich da das zweite -Werror löschen? -- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hello, On Sun, 15 Feb 2009, Sascha 'saigkill' Manns wrote:
On Sonntag 15 Februar 2009 21:56:31 David Haller wrote:
Hello,
On Sun, 15 Feb 2009, Sascha 'saigkill' Manns wrote:
Hallo Freunde,
momentan baue ich libdbus++, aber make bricht ab bei:
g++ [..] -Werror [..] cc1plus: warnings being treated as errors
Hier steht's.
.../tinyxmlparser.cpp: In static member function 'static const char* TiXmlBase::SkipWhiteSpace(const char*, TiXmlEncoding)': .../tinyxmlparser.cpp:357: error: suggest parentheses around && within || make[3]: *** [tinyxmlparser.lo] Error 1
Was fehlt mir da?
Nix. Du hast ein '-Werror' zuviel in den CFLAGS. Guck mal bei den configure-Optionen, das wird gerne per '--enable-maintainer-mode' oder eine extra Option (z.B. --enable-werror) angefügt. Also ich habe es rekonstruiert. Make war im Verzeichnis src/release. So bin ich in das Verzeichnis gegangen und dann im Makefile geschaut. Die Meldung beinhaltete "tinyxmlparser.cpp". Im Makefile gab es auch diesen Abschnitt mit "tinyxmlparser.cpp". Er lautete: @am__fastdepCXX_TRUE@ $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -MT tinyxmlparser.lo -MD -MP -MF $(DEPDIR)/tinyxmlparser.Tpo -c -o tinyxmlparser.lo `test -f '../tinyxmlparser.cpp' || echo '$(srcdir)/'`../tinyxmlparser.cpp
Ist das der richtige Abschnitt? Wo kann ich da das zweite -Werror löschen?
Wie lautet denn dein ./configure Aufruf? Und schau mal die configure Optionen durch, ob das nicht auch abschaltbar ist. -dnh -- "Im Grunde ist es verblüffend, daß ein so phallisches Zeichen wie das erigierte I von der Lilafraktion als Zeichen für Geschlechtergerechtigkeit angesehen wird" -- Martin Gerdes in desd über "geschlechtsneutrale" SchreiberInnen -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hello,
On Sun, 15 Feb 2009, Sascha 'saigkill' Manns wrote:
On Sonntag 15 Februar 2009 21:56:31 David Haller wrote:
Hello,
On Sun, 15 Feb 2009, Sascha 'saigkill' Manns wrote:
Hallo Freunde,
momentan baue ich libdbus++, aber make bricht ab bei:
g++ [..] -Werror [..] cc1plus: warnings being treated as errors
Hier steht's.
.../tinyxmlparser.cpp: In static member function 'static const char* TiXmlBase::SkipWhiteSpace(const char*, TiXmlEncoding)': .../tinyxmlparser.cpp:357: error: suggest parentheses around && within || make[3]: *** [tinyxmlparser.lo] Error 1
Was fehlt mir da?
Nix. Du hast ein '-Werror' zuviel in den CFLAGS. Guck mal bei den configure-Optionen, das wird gerne per '--enable-maintainer-mode' oder eine extra Option (z.B. --enable-werror) angefügt.
Also ich habe es rekonstruiert. Make war im Verzeichnis src/release. So bin ich in das Verzeichnis gegangen und dann im Makefile geschaut. Die Meldung beinhaltete "tinyxmlparser.cpp". Im Makefile gab es auch diesen Abschnitt mit "tinyxmlparser.cpp". Er lautete: @am__fastdepCXX_TRUE@ $(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) $(CXXFLAGS) -MT tinyxmlparser.lo -MD -MP -MF $(DEPDIR)/tinyxmlparser.Tpo -c -o tinyxmlparser.lo `test -f '../tinyxmlparser.cpp' || echo '$(srcdir)/'`../tinyxmlparser.cpp
Ist das der richtige Abschnitt? Wo kann ich da das zweite -Werror löschen?
Wie lautet denn dein ./configure Aufruf? Und schau mal die configure Optionen durch, ob das nicht auch abschaltbar ist. Ich nehme das %configure Makro vom Build Service. Configure bitetet folgende Optionen: Configuration: -h, --help display this help and exit --help=short display options specific to this package --help=recursive display the short help of all the included
On Montag 16 Februar 2009 00:09:16 David Haller wrote: packages -V, --version display version information and exit -q, --quiet, --silent do not print `checking...' messages --cache-file=FILE cache test results in FILE [disabled] -C, --config-cache alias for `--cache-file=config.cache' -n, --no-create do not create output files --srcdir=DIR find the sources in DIR [configure dir or `..'] Installation directories: --prefix=PREFIX install architecture-independent files in PREFIX [/usr/local] --exec-prefix=EPREFIX install architecture-dependent files in EPREFIX [PREFIX] By default, `make install' will install all the files in `/usr/local/bin', `/usr/local/lib' etc. You can specify an installation prefix other than `/usr/local' using `--prefix', for instance `--prefix=$HOME'. For better control, use the options below. Fine tuning of the installation directories: --bindir=DIR user executables [EPREFIX/bin] --sbindir=DIR system admin executables [EPREFIX/sbin] --libexecdir=DIR program executables [EPREFIX/libexec] --sysconfdir=DIR read-only single-machine data [PREFIX/etc] --sharedstatedir=DIR modifiable architecture-independent data [PREFIX/com] --localstatedir=DIR modifiable single-machine data [PREFIX/var] --libdir=DIR object code libraries [EPREFIX/lib] --includedir=DIR C header files [PREFIX/include] --oldincludedir=DIR C header files for non-gcc [/usr/include] --datarootdir=DIR read-only arch.-independent data root [PREFIX/share] --datadir=DIR read-only architecture-independent data [DATAROOTDIR] --infodir=DIR info documentation [DATAROOTDIR/info] --localedir=DIR locale-dependent data [DATAROOTDIR/locale] --mandir=DIR man documentation [DATAROOTDIR/man] --docdir=DIR documentation root [DATAROOTDIR/doc/libdbus++] --htmldir=DIR html documentation [DOCDIR] --dvidir=DIR dvi documentation [DOCDIR] --pdfdir=DIR pdf documentation [DOCDIR] --psdir=DIR ps documentation [DOCDIR] Program names: --program-prefix=PREFIX prepend PREFIX to installed program names --program-suffix=SUFFIX append SUFFIX to installed program names --program-transform-name=PROGRAM run sed PROGRAM on installed program names System types: --build=BUILD configure for building on BUILD [guessed] --host=HOST cross-compile to build programs to run on HOST [BUILD] Optional Features: --disable-FEATURE do not include FEATURE (same as --enable- FEATURE=no) --enable-FEATURE[=ARG] include FEATURE [ARG=yes] --enable-dev for development only -- do not use --enable-shared[=PKGS] build shared libraries [default=yes] --enable-static[=PKGS] build static libraries [default=yes] --enable-fast-install[=PKGS] optimize for fast installation [default=yes] --disable-libtool-lock avoid locking (might break parallel builds) --disable-dependency-tracking speeds up one-time build --enable-dependency-tracking do not reject slow dependency extractors Optional Packages: --with-PACKAGE[=ARG] use PACKAGE [ARG=yes] --without-PACKAGE do not use PACKAGE (same as --with-PACKAGE=no) --with-debug in addition to release version, build debug version of library --with-thread in addition build thread-safe version of library --with-doc build DOXYGEN documentation (requires Doxygen) --with-gnu-ld assume the C compiler uses GNU ld [default=no] --with-pic try to use only PIC/non-PIC objects [default=use both] --with-tags[=TAGS] include additional configurations [automatic] Some influential environment variables: PKG_CONFIG path to pkg-config utility CXX C++ compiler command CXXFLAGS C++ compiler flags LDFLAGS linker flags, e.g. -L<lib dir> if you have libraries in a nonstandard directory <lib dir> LIBS libraries to pass to the linker, e.g. -l<library> CPPFLAGS C/C++/Objective C preprocessor flags, e.g. -I<include dir> if you have headers in a nonstandard directory <include dir> CC C compiler command CFLAGS C compiler flags CPP C preprocessor CXXCPP C++ preprocessor F77 Fortran 77 compiler command FFLAGS Fortran 77 compiler flags DBUS_CFLAGS C compiler flags for DBUS, overriding pkg-config DBUS_LIBS linker flags for DBUS, overriding pkg-config -- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hello, [grad fällt mir auf, ich hab diese ML noch nicht auf 'de' umgestellt ;)] On Mon, 16 Feb 2009, Sascha 'saigkill' Manns wrote:
On Montag 16 Februar 2009 00:09:16 David Haller wrote:
On Sun, 15 Feb 2009, Sascha 'saigkill' Manns wrote:
On Sonntag 15 Februar 2009 21:56:31 David Haller wrote:
On Sun, 15 Feb 2009, Sascha 'saigkill' Manns wrote:
momentan baue ich libdbus++, aber make bricht ab bei:
g++ [..] -Werror [..] cc1plus: warnings being treated as errors [..] Ich nehme das %configure Makro vom Build Service.
Ok, ich hab jetzt mal ins Paket geschaut, im configure[.] werden die cxxflags explizit mit -Werror gesetzt. Abhilfe: sed -i '/^-Werror/d' configure (es gibt im configure nur diese eine Stelle, wo das -Werror am Zeilenanfang vorkommt). Alternativ könntest du '-Wno-parentheses' ergänzen, aber evtl. klemmt es noch bei anderen Sachen (-Wsign-compare ist beliebt als Warnung, die mit -Werror natürlich auch zum Fehler wird). BTW: ich hasse es, wenn Quellen veröffentlicht werden, die _offensichtlich_ nicht geprüft wurden, d.h. die (mit "-O2 -march=foo" oder so als CFLAGS/CXXFLAGS) nicht ohne Tricks kompiliert werden können (mit -Wno-parentheses _nach_ dem -Wall könnte es durchlaufen). *grummel* Ich wünsch mir da öfter mal nen Fisch von Verleihnix, den ich den Verantwortlichen um die Ohren hauen kann ;) HTH, -dnh -- Macht kann nur in den Kopf steigen, wenn Platz dafür da ist. -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Montag 16 Februar 2009 01:13:56 David Haller wrote:
On Mon, 16 Feb 2009, Sascha 'saigkill' Manns wrote:
On Montag 16 Februar 2009 00:09:16 David Haller wrote:
On Sun, 15 Feb 2009, Sascha 'saigkill' Manns wrote:
On Sonntag 15 Februar 2009 21:56:31 David Haller wrote:
On Sun, 15 Feb 2009, Sascha 'saigkill' Manns wrote:
momentan baue ich libdbus++, aber make bricht ab bei:
g++ [..] -Werror [..] cc1plus: warnings being treated as errors
[..]
Ich nehme das %configure Makro vom Build Service.
Ok, ich hab jetzt mal ins Paket geschaut, im configure[.] werden die cxxflags explizit mit -Werror gesetzt.
Abhilfe: sed -i '/^-Werror/d' configure Danke sehr, das hat funktioniert. Ist kaum zu glauben, dass du nach kurzem sichten des Quellcodes, gleich die richtige Stelle gefunden hast. Ich merke, hier kann ich noch viel lernen.
Ich wünsch mir da öfter mal nen Fisch von Verleihnix, den ich den Verantwortlichen um die Ohren hauen kann ;) Ich auch. Wir haben bei unseren Paketen zum releasen ein weit höheres Niveau als manche Programmierer.
-- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Nabend, wie würde man diesen Fehler fachmännisch lösen? libdbus++.i586: E: shlib-policy-name-error (Badness: 10000) libdbus++-0_6_0 Your package contains a single shared library but is not named after its SONAME. In einem anderen Paket habe ich im %install Bereich manuell einen sonamen vergeben. Aber mich würde interessieren, wie würdet ihr obigen Fehler angehen? Und auch wie vergebe ich Versionsnummern für so-Files? -- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Hallo Leute, ich wollte mich gerne nochmals bedanken. Ich habe die Specs gesichtet, und finde, dass ihr Sachen eingebaut habt, die ich wirklich noch _nie_ gesehen habe. Ich lerne hier echt dazu... -- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Servus Leute, jetzt habe ich folgendes Problem (Lösung Philip): configure.in:106: error: possibly undefined macro: AC_MSG_ERROR If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:137: error: possibly undefined macro: AC_CPP_NAMESPACE configure.in:138: error: possibly undefined macro: AC_CPP_BOOL configure.in:139: error: possibly undefined macro: AC_CPP_EXPLICIT configure.in:189: error: possibly undefined macro: AC_DOXYGEN_DOC Zuerst dachte ich, es läge am fehlenden doxygen_doc aber das habe ich bereits eingefügt als BR. -- Sincereley yours Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090217 10:04]:
Zuerst dachte ich, es läge am fehlenden doxygen_doc aber das habe ich bereits eingefügt als BR.
Da habe ich wohl Murks gemacht, Sorry! Ich schu mir's gleich mal an. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Dienstag 17 Februar 2009 12:19:23 Philipp Thomas wrote:
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090217 10:04]:
Zuerst dachte ich, es läge am fehlenden doxygen_doc aber das habe ich bereits eingefügt als BR.
Da habe ich wohl Murks gemacht, Sorry! Ich schu mir's gleich mal an. Jetzt baut er durch bis zur Filelist. Das bearbeite ich noch. Ansonsten klappe die kombination beider Vorschläge. Philips habe ich als grundlage genommen und Davids Patch bezgl- Versionierung eingebaut. Wenn man dann noch autoreconf auskommentiert klappts :-) Ich werde euch auf dem laufenden halten.. Vielen Dank bisher erstmal für die Hilfe. Manche Sachen, werde ich in meine anderen Pakete auch einbauen. @Philip: Dein Patch schließt eine statische Library aus. Kann man das generell immer machen in Paketen, die mit lib* beginnen? -- Sincereley yours
Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090217 13:22]:
grundlage genommen und Davids Patch bezgl- Versionierung eingebaut.
Die Versionierung von libdbus++ ist in Ordnung so wie sie ist! Da muss nichts dran geändert werden. Wie ich in der anderen Mail schrieb, ist <name>-<version>.so eine zulässige Versionierung. Einfach blind .so.major.minor.patch und .so.major mit Soname=<name>.so.major zu verwenden führt in dem Moment zu Problemen, wo Upstream Änderungen des ABI ohne raufzählen der Major-version gemacht werden.
man dann noch autoreconf auskommentiert klappts :-)
Der Einbau von autoreconf geschah mit Absicht. Wenn Da was schiefgeht muss an anderer Stelle gearbeitet werden. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Dienstag 17 Februar 2009 14:20:26 Philipp Thomas wrote:
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090217 13:22]:
grundlage genommen und Davids Patch bezgl- Versionierung eingebaut.
Die Versionierung von libdbus++ ist in Ordnung so wie sie ist! Da muss nichts dran geändert werden. OK habs wieder rausgeschmissen. Hat mir halt irgendwie gefallen so.0.6.0
wo Upstream Änderungen des ABI ohne raufzählen der Major-version gemacht werden. Wer oder was ist ABI?
man dann noch autoreconf auskommentiert klappts :-)
Der Einbau von autoreconf geschah mit Absicht. Wenn Da was schiefgeht muss an anderer Stelle gearbeitet werden. OK. Dann müssen wir nur noch den Patch irgendwie überarbeiten... -- Sincereley yours
Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090217 15:04]:
Wer oder was ist ABI?
ABI steht für Application Binary Interface, alswo die Schnittstelle(n), die eine binäre Bibliothek einer Anwendung bietet. Also zum Beispiel die Zahl und Art der Parameter, die eine nach aussen sichtbare Bibliotheksfunktion erwartet. Wenn diese Bibliothek einen Soname bibliothek.so.Hauptversion hat, so muss sichergestellt sein, das in allen Versionen mit der gleichen Hauptversion (die dann ja den gleichen Soname haben), sich an diesen Parametern nichts ändert. Beziehungsweise dass eben die Hauptversion erhöht wird wenn sich etwas ändert. Es gibt auch noch eine andere Möglichkeit, diesem Problem zu begegegnen, aber das wird nur von sehr wenigen Bibliotheken verwendet: die Symbolversionen. Hier wird jedem extern sichtbaren Symbol (also z.B. Variablen und Funktionen) eine Version zugeordnet. Damit braucht einem Symbol nur noch eine andere Version zugeordnet zu werden ohne das sich die Version der ganzen Bibliothek ändert. So liefert z.B. auch meiner x86_64 Maschine ein 'objdump -T /lib64/libc.so.6' (Ausschnitt): 00000000000c5300 g DF .text 000000000000017b GLIBC_2.4 __xmknodat 0000000000064160 g DF .text 0000000000000274 GLIBC_2.2.5 _IO_fdopen 00000000000f33b0 g DF .text 00000000000000f9 GLIBC_2.3.3 inet6_option_find 0000000000088bb0 w DF .text 000000000000000a GLIBC_2.3 wcstoull_l 00000000000f6ae0 g DF .text 00000000000002f8 GLIBC_2.2.5 clnttcp_create Die vorletzte Spalte sind die Symbolversionen und ein 'objdump -p /lib64/libc.so.6' zeigt Dir unter anderem, welche Versionen eine Bibliothek verwendet.
OK. Dann müssen wir nur noch den Patch irgendwie überarbeiten...
Fehler ist schon gefunden :) Ich mach gleich ein submitreq damit Du die Änderungen bekommst. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Moin moin, Am Dienstag, 17. Februar 2009 15:31 schrieb Philipp Thomas:
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090217 15:04]:
Wer oder was ist ABI?
ABI steht für Application Binary Interface, alswo die Schnittstelle(n), die eine binäre Bibliothek einer Anwendung bietet.
Hmm, laut Wikipedia ist damit die Hardware Ebene gemeint, nicht unbedingt die API... Verstehe ich das falsch? http://de.wikipedia.org/wiki/Bin%C3%A4rschnittstelle Zitait ---> Es wird definiert, wie der Programmcode auf Ebene der Maschinensprache auszusehen hat, der eine solche Schnittstelle verwendet. Beispiele dafür sind die Reservierung von bestimmten Prozessorregistern für bestimmte Zwecke, die Richtung des Stacks oder das Format von Gleitkommazahlen. Eine Binärschnittstelle unterscheidet sich von einer Programmierschnittstelle (API) (englisch application programming interface) darin, dass die Programmierschnittstelle eine Schnittstelle auf Quelltextebene definiert. Dadurch lässt sich der Quelltext auf verschiedenen Maschinen kompilieren, die die Programmierschnittstelle unterstützen. Die Binärschnittstelle dagegen erlaubt den Betrieb auf allen Systemen, die eine binärkompatible Schnittstelle zur Verfügung stellen, ohne dass ein Neukompilieren erforderlich wäre. <------ zitat ende Ich bin nachdenklich geworden, weil in Zusammenhang verschiedener GCC Versionen manchmal ein Sprung in der ABI Version ist: Z.B. gcc 3.3.5 auf gcc 3.4.6 (ABI Version 3 -> ABI Version 4)... Wie verhält sich das nun genau??? Viele Grüsse Andre -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
* Andre Heine (linux-experience@gmx.net) [20090217 16:09]:
Hmm, laut Wikipedia ist damit die Hardware Ebene gemeint, nicht unbedingt die API...
Zum einen irrt Wikipedia, zum anderen ist es nicht das API! API ist die Schnittstelle, die sich Dir zum Programmieren (das P in API :) bietet. Wenn diese Schnittstelle in einer kompilierten Bibliothek vorliegt, spricht man vom ABI. Hier *müssen* die Schnittstellen passen, denn es handelt sich letztendlich um Maschienencode. Überleg mal was passiert, wenn sich z.B. die Argumente einer Funktion ändern, also zum Beispiel ein Parameter hinzukommt, das Programm aber eben einen Parameter zu wenig übergibt. Dann wird der der Code der Bibliothek irgendwelchen Müll vom Stack verarbeiten.
Programmierschnittstelle eine Schnittstelle auf Quelltextebene definiert.
Eben :) Auf Quelltextebene, nicht auf Ebene der kompilierten Bibliothek.
die eine binärkompatible Schnittstelle zur Verfügung stellen, ohne dass ein Neukompilieren erforderlich wäre.
Eben deshalb muss eine Änderung des ABI mit der Erhöhung der Hauptversion verbunden sein, damit die Applikation, welche die neue Bibliothek nutzen will neu kompiliert werden muss. So verständlich?
Z.B. gcc 3.3.5 auf gcc 3.4.6 (ABI Version 3 -> ABI Version 4)...
Wie verhält sich das nun genau???
Genau wie ich geschrieben habe. Hier hatte sich dass vom GCC unterstützte ABI geändert. Des müssen alle Bibliotheken und Applikationen mit der gleichen Compiler-Version übersetzt werden, damit sie sich auch verstehen können. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Dienstag, 17. Februar 2009 18:42 schrieb Philipp Thomas:
* Andre Heine (linux-experience@gmx.net) [20090217 16:09]:
Hmm, laut Wikipedia ist damit die Hardware Ebene gemeint, nicht unbedingt die API...
Zum einen irrt Wikipedia, zum anderen ist es nicht das API!
Könnt Ihr das da nicht mal richtig stellen:-)
API ist die Schnittstelle, die sich Dir zum Programmieren (das P in API :) bietet. Wenn diese Schnittstelle in einer kompilierten Bibliothek vorliegt, spricht man vom ABI. Hier *müssen* die Schnittstellen passen, denn es handelt sich letztendlich um Maschienencode. Überleg mal was passiert, wenn sich z.B. die Argumente einer Funktion ändern, also zum Beispiel ein Parameter hinzukommt, das Programm aber eben einen Parameter zu wenig übergibt.
Ja, das habe ich verwechelt mit der API. Diese habe ich ja als Entwickler verändert. Daher muss ich neukompilieren... (modifizierte Header, etc ...) Jetzt habe ich vermutet, dass die ABI Version durch den Compiler vorgegeben wird. Damit meine ich, das jetzt der gcc3.3.5 die ABI Version "3" erzeugt, also das Binaryformat (ELF?) die ABI Version "3" hat. Das vertausche ich eventuell!? Würde ich den selben Quellcode mit dem gcc 4.2 compilieren, wäre die API meiner Library immer noch gleich. An den Parametern hat sich nichts verändert, trotzdem stimmt aber die ABI Version nicht und muss neu kompilieren... Das hatte ich bislang immer so angenommen...
Programmierschnittstelle eine Schnittstelle auf Quelltextebene definiert.
Eben :) Auf Quelltextebene, nicht auf Ebene der kompilierten Bibliothek.
die eine binärkompatible Schnittstelle zur Verfügung stellen, ohne dass ein Neukompilieren erforderlich wäre.
Eben deshalb muss eine Änderung des ABI mit der Erhöhung der Hauptversion verbunden sein, damit die Applikation, welche die neue Bibliothek nutzen will neu kompiliert werden muss. So verständlich?
Mir ist noch nicht der Zusammenhang zwischen der "Art und Anzahl" der Parameter und der ABI Version klar. Weil ich eben bis gestern glaubte, das ich als Entwickler die "Art und Anzahl" vorgebe... Durch _meine_ definierte API. Mit der ABI habe ich ja erstmal nichts am Hut...
Z.B. gcc 3.3.5 auf gcc 3.4.6 (ABI Version 3 -> ABI Version 4)...
Wie verhält sich das nun genau???
Genau wie ich geschrieben habe. Hier hatte sich dass vom GCC unterstützte ABI geändert. Des müssen alle Bibliotheken und Applikationen mit der gleichen Compiler-Version übersetzt werden, damit sie sich auch verstehen können.
Ja, genau. Ändert sich die ABI, muss ich neu komplieren. Auch wenn die API immer noch die selbe ist... Will so erstmal nicht in meinen Kopf, aber ich arbeite dran:-) Andre -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
So, jetzt ist _etwas_ klarer... Am Mittwoch, 18. Februar 2009 09:57 schrieb Andre Heine:
Ja, genau. Ändert sich die ABI, muss ich neu komplieren. Auch wenn die API immer noch die selbe ist...
Will so erstmal nicht in meinen Kopf, aber ich arbeite dran:-)
https://forum.bsdgroup.de/showthread.php?t=882 Jetzt verstehe ich etwas besser, die ABI umfasst etwas mehr... Ich habe Dich da wohl etwas missverstanden. Ändere ich die API, kann das sebstverständlich auch die ABI ändern. Das war mir so direkt nicht klar, dachte das dies alles durch den Compiler passiert. Das die Änderung eines Types von int zu long in der Signatur auch die ABI ändert ist neu:-) Du scheinst da jedenfalls nicht so ganz unrecht zu haben. Auch wenn ich immernoch der Meinung bin, das eine Änderung der Signatur eine Änderung der API ist und daher so oder so neu kompiliert werden sollte... Wie immer, der Teufel steckt im Detail... Viele Grüsse und Dank für die Erklärungen... Andre -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Wed, 18 Feb 2009 11:23:47 +0100 schriebst Du:
Das die Änderung eines Types von int zu long in der Signatur auch die ABI ändert ist neu:-)
Nicht zwansläufig :) Bei C++ fliesst ja der Datentyp direkt in die Namensdekoration
ein. Mach mal ein 'objdump --demangle -T /usr/lib64/libstdc++.so.6', dann
bekommst Du (Ausschnitt):
00067a70 w DF .text 00000015 GLIBCXX_3.4 std::basic_ios
Auch wenn ich immernoch der Meinung bin, das eine Änderung der Signatur eine Änderung der API ist und daher so oder so neu kompiliert werden sollte...
Wie soll das aber die Applikation merken? Wenn ich eine kompilierte Applikation habe und nun eine neue Version der Bibliothek einspiele erwarte ich, dass diese Applikation nach wie vor vernünftig funktioniert. Das aber ist (unter anderem) nur garantiert, wenn das ABI nicht verändert wurde. Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Mittwoch, 18. Februar 2009 12:44 schrieb Philipp Thomas:
Am Wed, 18 Feb 2009 11:23:47 +0100 schriebst Du:
Das die Änderung eines Types von int zu long in der Signatur auch die ABI ändert ist neu:-)
Nicht zwansläufig :) Bei C++ fliesst ja der Datentyp direkt in die Namensdekoration ein. Mach mal ein 'objdump --demangle -T /usr/lib64/libstdc++.so.6', dann bekommst Du (Ausschnitt):
So verstehe ich... Du hattest das Beispiel mit Art+Parameter gebracht und die Signatur definiert ja der Entwickler... ( und somit auch einen Teil der ABI, wie ich jetzt weiss ...) Daher habe ich den Link gemailt:-() [...]
Wie soll das aber die Applikation merken? Wenn ich eine kompilierte Applikation habe und nun eine neue Version der Bibliothek einspiele erwarte ich, dass diese Applikation nach wie vor vernünftig funktioniert. Das aber ist (unter anderem) nur garantiert, wenn das ABI nicht verändert wurde.
Ja, das stimmt ja auch. Die andere Applikation merkt es natürlich erst dann, wenn sie "Explodiert":-) Da muss die Version stimmen. Weshalb ich jetzt _beides_ neu kompilieren würde um ggf. Fehler zu finden... (Das sollte ja eigentlich der Compiler anzeigen...) Das ist aber ein anderes Problem, nämlich eins von Oraganisatorischer Natur. Du hattest in etwa geschrieben (was auch so richtig ist, ich habe es nur in den falschen Hals bekommen). "Also zum Beispiel die Zahl und Art der Parameter ..." (rest entfernt) Die Art+Parameter werden ja erstmal durch den Entwickler festgelegt (API), daher meine Verwechslung/Unwissendheit. Soweit hatte ich aber gar nicht gedacht. Für MICH war in dem Moment klar, dass Du hier etwas verwechselt hast (was nicht so war/ist, sondern ICH habe es verwechelt bzw. hatte hier eine Wissenslücke)... Fazit: - Wenn ich meine API ändere, ändere ich auch meine ABI. - Ich kann die ABI auch ohne API Änderung z.B. durch falschen Compiler verändern... - die Architektur des systems bestimmt einen Teil der ABI (64bit) - Grundsätzlich sollte man immer alle Teile einer Apllikation PRÜFEN, wenn sich API/ABI ändern könnte... Andre -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Wed, 18 Feb 2009 09:57:01 +0100 schriebst Du:
Jetzt habe ich vermutet, dass die ABI Version durch den Compiler vorgegeben wird. Damit meine ich, das jetzt der gcc3.3.5 die ABI Version "3" erzeugt, also das Binaryformat (ELF?) die ABI Version "3" hat.
Das vertausche ich eventuell!?
Nein, hier ist von C++ die Rede und da sehen die Sachen noch etwas andwers aus. Bei C++ gehören auch solche Dinge wie die Kodierung von Parametern im Namen der Funktion (das sog. name mangling) zum ABI, eben zum C++ ABI. Ausserdem gibt es dann noch Plattformspezifische ABIs wie z.B: das für x86_64. In solchen ABI werden so Dinge festgelegt wie in welchen Registern welche Form von Daten übergeben werden, ob überhaupt in Registern oder dem Stack und so weiter.
Würde ich den selben Quellcode mit dem gcc 4.2 compilieren, wäre die API meiner Library immer noch gleich. An den Parametern hat sich nichts verändert, trotzdem stimmt aber die ABI Version nicht und muss neu kompilieren...
Ja, wegen des C++ ABIs.
Mit der ABI habe ich ja erstmal nichts am Hut...
Es gibt halt viele Formen von ABI :) Auf die Schnittstelle Deiner Bibliothek hast Du noch Einfluss, aber eben nicht z.B. auf das name mangling des C++ Compilers.
Will so erstmal nicht in meinen Kopf, aber ich arbeite dran:-)
Habe ich mich jetzt verständlicher ausgedrückt? Philipp -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
Am Mittwoch, 18. Februar 2009 12:08 schrieb Philipp Thomas:
Will so erstmal nicht in meinen Kopf, aber ich arbeite dran:-)
Habe ich mich jetzt verständlicher ausgedrückt?
Jep, danke für die Mühe! Viele Grüsse Andre -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
On Dienstag 17 Februar 2009 12:19:23 Philipp Thomas wrote:
* Sascha 'saigkill' Manns (samannsml@directbox.com) [20090217 10:04]:
Zuerst dachte ich, es läge am fehlenden doxygen_doc aber das habe ich bereits eingefügt als BR.
Da habe ich wohl Murks gemacht, Sorry! Ich schu mir's gleich mal an. Das scheint auch mit am Patch zu liegen. Wenn ich den deaktiviere, autoreconf und make -p m4 auch deaktiviere, läuft er durch bis zur Filelist. Allerdings baut er die statischen gleich mit. Also irgendwo im Patch muss noch der Wurm drin sein ... -- Sincereley yours
Sascha Manns openSUSE Marketing Team (Weekly News) openSUSE Build Service Web: http://saschamanns.gulli.to Blog: http://lizards.opensuse.org/author/saigkill -- To unsubscribe, e-mail: opensuse-programming-de+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-programming-de+help@opensuse.org
participants (5)
-
Andre Heine
-
David Haller
-
Philipp Thomas
-
Philipp Thomas
-
Sascha 'saigkill' Manns