Software > Programmieren, Kompilieren

fluxbox compile error

<< < (2/3) > >>

erisch:
achso, jetzt fällt es mir erst auf: die libiconv steht doch garnicht mit bei den einzubindenden Libraries mit drin.

Wenn er nur bei diesem g++ libiconv nicht findet, dann gehste in das Verzeichnis wo er das g++ ausgeführt hatte (er zeigt dir das ja an, wo er war, da steht irgendwas von "leaving /bla/blu/blo")
dann pastest du das gesamte g++ Konstrukt was den Fehler erzeugt und hängst ein "-liconv" dran.

Falls es bei mehreren Kompilierungen fehlt, kannste entweder "-liconv" mit in die Makefile (an entsprechnder Stelle) einfügen oder du änderst wieder die LDFLAGS:

--- Code: ---export LDFLAGS="$LDFLAGS -liconv"
--- Ende Code ---



Jetzt sollte es aber klappen ;)

Falls immernoch nicht, dann versuch mal die libiconv selbst zu kompilieren. Sollte ohne Anstalten funktionieren.
Das mit den Wrong ELF Class Fehler hat was damit zu tun, dass du ein 64 Bit Object mit einer 32 Bit Library linken willst (oder andersrum). Im Allgemeinen würde ich empfehlen, immer 32 Bit zu kompilieren. Ist zu 99% schneller als 64Bit Binaries.

Mfg. Erisch

cutoff:
damn, genau das gleiche problem.
ich geb's bald auf ...

fast immer der gleiche mist beim compilen auf den sun buechsen.
bis auf xchat und aterm treten staendig probleme beim compilieren der applikationen auf, welche ich installieren moechte.
und der mensch, der immer die sparc packages fuer fluxbox baute, ist nicht mehr aktiv in der richtung. *grrr*

erisch, mach ma 'nen deal: du compilierst das ding, baust nen package draus und machst es mir dann zugaenglich.
und wenn du dann mal in muenchen bist, gebe ich dir ein bier aus   ;D

make clean & done

erisch:
hab im moment keine sun mit gcc drauf. Aber werd ich wohl mal wieder was machen müssen ;)

Auf jeden Fall kriegt man fast alles auf Sun kompiliert. Vor allem ist es ja noch einfach, wenn man nur den GCC verwendet, fang mal mit dem SunC Pro an ...

Mal sehen was sich machen lässt

Mfg. Erisch

erisch (als gast):
So

Wie ich sehe, hast du ja Sol10 drauf. Da kommen wir zu Problem Nr. 1:
Ich hab im Moment keine Ultra und seit Sol10 hat sich doch einiges bei kompilieren geändert.
Ich kann es natürlich mit Sol9 versuchen, aber es muss dann nicht funktionieren.
Das beste wäre also, wenn ich ssh Zugriff auf die Maschine hätte. Dann kann ich das Zeugs gleich auf deiner Kiste kompilieren.

Aber vielleicht kriegste das auch noch selbst hin, nur nicht so schnell aufgeben. Wir wollen mal ganz logisch vorgehen.
Du hast also die libiconv drauf, dann schau zuerst mal ob du eine "libiconv.so" in deinem /usr/locla/lib Verzeichnis hast.
Dann müssen die Symbole  libiconv_close, libiconv_open und libiconv darin definiert sein. Um das herauszufinden kann man "nm" benutzen:

--- Code: ---nm /usr/local/lib/libiconv.so
--- Ende Code ---

Jetzt listet er die gesamten Symbole der libiconv auf, das könnten viele sein, deswegen das Ergebnis filtern:

--- Code: ---nm /usr/local/lib/libiconv.so |grep libiconv_close
--- Ende Code ---

Wenn du jetzt garnix erhälst, fehlt das Symbol in der libiconv, ansonsten kriegst du ne Zeile mit Infos, die in etwa so aussieht: (das ist jetzt eine andere Library, nicht wundern)

--- Code: ---[193]   |   167450144|            |Proc    |                  |Undefined| __ull_rshift
--- Ende Code ---

Aber auch das ist nix gutes, weil das Symbol in dieser Library nicht definiert ist. Das sagt dir das "Undefined" in der vorletzten Spalte. Wenn dort "Text" oder "Common" oder sonstwas steht, ist (wahrscheinlich) alles in Ordnung und du kannst die anderen 2 Symbole noch checken.

Falls aber das Symbol nicht vorhanden oder undefined ist, muss es in einer anderen Library stehen. Soweit ich weiß ist libiconv aber ein Basisprogramm, was keine weiteren Abhängigkeiten hat. Das sunfreeware-Paket ist eigentlich auch in Ordnung, hab ich glaubich selbst schon verwendet. Deswegen dürfte der Fall des "undefined" oder dass er gar nix ausgibt eher unwahrscheinlich sein.

Also sollte bis hier alles in Ordnung sein, wenn nicht, dann müssen wir woanders ansetzen.

Dann versuchen wir es noch mal mit dem kompilieren:

Versuch mal folgendes:

--- Code: ---g++ -g -O2 -I/usr/openwin/include -DSHAPE -I/usr/openwin/include -I/usr/sfw/include -I/usr/sfw/include/freetype2 -o fluxbox ArrowButton.o FbAtoms.o FbWinFrame.o FbWinFrameTheme.o fluxbox.o Keys.o main.o Netizen.o RootTheme.o FbRootWindow.o Screen.o ScreenResources.o Slit.o SlitTheme.o SlitClient.o WinButton.o WinButtonTheme.o Window.o Workspace.o FbCommands.o IntResMenuItem.o FbMenu.o WinClient.o Xutil.o CurrentWindowCmd.o WorkspaceCmd.o CommandParser.o FbCommandFactory.o Shape.o MenuTheme.o Container.o TextTheme.o BorderTheme.o CommandDialog.o SendToMenu.o Parser.o FbMenuParser.o StyleMenuItem.o RootCmdMenuItem.o MenuCreator.o IconMenu.o WorkspaceMenu.o HeadArea.o Resources.o Ewmh.o Gnome.o Remember.o RegExp.o ClientPattern.o Toolbar.o ToolbarTheme.o ToolbarItem.o ClockTool.o WorkspaceNameTool.o IconbarTool.o IconbarTheme.o ToolTheme.o IconButton.o SystemTray.o GenericTool.o ButtonTool.o ButtonTheme.o ToolFactory.o  -L/usr/openwin/lib -lSM -lICE FbTk/libFbTk.a -lnsl -lsocket -lX11 -lXext -L/usr/local/lib -liconv -L/usr/sfw/lib -L/usr/openwin/sfw/lib -lXft -lfreetype -lfontconfig -lXrender -lXpm -Wl,-R -Wl,/usr/openwin/lib -Wl,-R -Wl,/usr/sfw/lib -Wl,-R -Wl,/usr/openwin/lib:/usr/openwin/sfw/lib
--- Ende Code ---


Die Änderungen die ich gemacht habe ist eine Kombination von den Hinweisen der vorherigen Posts.
Den Befehl musst du natürlich im richtigen Verzeichnis ausführen, wie vorher schon gesagt.

Wenn es jetzt den den selben Fehler wieder bringt, obwohl du vorher in der libiconv.so alle Symbole gefunden hast, dann wirds echt eng mit weiteren Lösungsvorschlägen.
Was ich noch vorschlagen würde, vor alledem mal den LD_LIBRARY_PATH zu entrümpeln, möglichst ganz leermachen. Der macht nämlich schnell mal Probleme. Wie gesagt, ich empfehle crle zu verwenden. Den LIBRARY_PATH solltest du wirklich nur dann verwenden, wenn du keinen root-Zugriff hast oder wenn du in Startskripten von Programmen zusätzliche Bibliotheken brauchst (Mozilla macht das z.B. so)

Es gibt noch eine weitere Möglichkeit:

Die Solaris libc hat ein eingebautes iconv, das wird aber nur benutzt wenn configure keine libiconv findet oder das configure einen Schalter besitzt, um es nicht zu benutzen. ./configure --help gibt darüber auskunft.

So, versuch das alles erstmal.

Mfg. Erisch

cutoff:
jo, die objeckte sind der lib zwar bekannt, aber UNDEF :(

-bash-2.05b$ nm /usr/local/lib/libiconv.so | grep close
[793]   |         0|       0|FUNC |GLOB |0    |UNDEF  |fclose
[806]   |    115364|      20|FUNC |GLOB |0    |8      |libiconv_close
-bash-2.05b$ nm /usr/local/lib/libiconv.so | grep open
[792]   |         0|       0|FUNC |GLOB |0    |UNDEF  |fopen
[817]   |    114036|    1248|FUNC |GLOB |0    |8      |libiconv_open
-bash-2.05b$ nm /usr/local/lib/libiconv.so | grep libiconv
/usr/local/lib/libiconv.so:
[1]     |         0|       0|FILE |LOCL |0    |ABS    |.libs/libiconv.so.2.1.0
[805]   |    976564|       4|OBJT |GLOB |0    |14     |_libiconv_version
[810]   |    115284|      80|FUNC |GLOB |0    |8      |libiconv
[806]   |    115364|      20|FUNC |GLOB |0    |8      |libiconv_close
[817]   |    114036|    1248|FUNC |GLOB |0    |8      |libiconv_open
[796]   |    115384|     276|FUNC |GLOB |0    |8      |libiconvctl
[800]   |    115836|     412|FUNC |GLOB |0    |8      |libiconvlist

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete

Zur normalen Ansicht wechseln