Eclipse-cdt - library project szivas.

 ( compi | 2008. március 25., kedd - 22:20 )

Szuksegem lenne egy kis segitsegre eclipse ugyben mert olyan viszonylag alap dolognak mondhato kerdest nem tudok megoldani, ami nelkul valodi c++ projectekre gyakorlatilag hasznalhatatlan lenne az eclipse, szoval biztos csak en nezek be valamit.

Adva van 1 workspace, benne 2 eclipse c++ project. Egy c++ library (hogy statikus vagy shared az most tulajdonkeppen mindegy de mindketto eseten mukodnie kellene a dolognak) es egy c++ executeable project. A cel hogy a librayban megvalositott dolgokat az executeable projectbol el tudjam erni. Az nem sajna mukodik, hogy siman fuggoseget allitok a library projectre az executeable projecten, a linker nem talalja a libraryban definialt szimbolumokat. Akarhogy zsonglorkodok, ezen a helyzeten egyszeruen nem birok valtoztatni, itt teljesen elakadtam. Mar az is gyanus, hogy ha shared library projectet forditok, csak .so file kepzodik, .a nem - static librarynal meg forditva.
Barmilyen otletet, akar RTFM-et is url megjelolessel szivesen veszek.

a valaszokat elore is koszi

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

senki?

Statikus könyvtárat utoljára igaz évekkel ezelőtt csináltam azt is VC++ 6.0 alatt. De szerintem az rendben van, hogy .so fájl képződik a dinamukus és .a fájl pedig a statikus lib fordításakor.

Miért?

Dinamukus lib (ez ugye Win alatt .dll kiterjesztés, Linux alatt .so).
1. Dinamukus betöltés, nincs szükség header fájlokra, nincshozzálinkelve a programodhoz: Ha így akarod használni, akkor be kell töltened (Win alatt "LoadLibrary", Linux alatt ha "dlopen" fügvényekkel). Ezek után kell lekérned a szükséges függvények címét, lásd linkek:
Linux alatt
Win alatt

2. Hozzálinkejük a dinamikus libet a saját programhoz (ez nagyon hasonló a statikus megoldáshoz):
"gcc -Wall -I/path/to/include-files -L/path/to/libraries prog.c -lctest -o prog"

Statikus lib hozzá lesz linkelve a programodhoz, így lefordított tárgykódnak elérhetőnek kell lennie a library path segítségével, ill. a statikus lib header fájljainak elérhetőnek kell lenni az include path segítségével. Ha elérhetőek a lib-ek és a heder fájl, és ezek összeillenek (a statikus libet az include path-ban lévő header-rel kell lefordítani) akkor működni kell a dolognak.
"cc -o executable-name prog.c -L/path/to/library-directory -lctest"

Attila, Perger
-----------------------------------------------------
"Az a szoftver, amelyiket nem fejlesztik, az halott!"

Ez így nem egészen igaz, az újabb gcc-k tudják azt (3.4.x-től biztosan), hogy dinamikus libet képesek használni linkelésnél. Nem kell hozzá libx.a. Mingw alatt is, de ott oda kell figyelni, hogy melyik (vagy mindegyik) szimbólum publikus legyen. Linux alatt minden automatikusan az. Ha tudod előre, hogy melyik dll/so-t fogja használni a progid (és vannak fejléceid hozzá), akkor linkelésnél meg kell adni őket a binárisodhoz és nem kell a hókuszpókusz a dlopen-el és társaival.

Az Eclipse-el kapcsolatos problémáról annyit, hogy ahogy itt olvasom, másnak se akar sikerülni. Szerintem használjj autmake+autoconf-ot, scons-t vagy cmake-t - sokkal tisztább és szárazabb érzés. :)

Idézet:
Ez így nem egészen igaz, az újabb gcc-k tudják azt (3.4.x-től biztosan), hogy dinamikus libet képesek használni linkelésnél. Nem kell hozzá libx.a

Erre irhatnal egy peldat. Marmint hogyan mondom meg a linkernek hogy ne libxyz.a-t keressen hanem libxyz.so-t es ahoz linkeljen stub hasznalata nelkul.

Idézet:
Szerintem használjj (sic) autmake+autoconf-ot, scons-t vagy cmake-t - sokkal tisztább és szárazabb érzés. :)

Az eclipse+cdt hasznalatanak pont az lenne lenyege hogy platformfuggetlen ide. Azaz ugyan azt ugyan ugy hasznalod linux, win32 es egyeb ala. Ha elkezdenek unix specifikus dolgokat hasznalni a projecthez akkor egyreszt pont ez tunne el, masresz a RAD jellege szunne meg teljesen a dolognak (pl egy uj osztaly es a hozza szukseges fajlok hozzaadasa a projecthez context menubol add->class oszt jonapot, nem kell semmi masban turkalni, lehet a kodot irni keruloutak nelkul.

Idézet:
Az Eclipse-el kapcsolatos problémáról annyit, hogy ahogy itt olvasom, másnak se akar sikerülni.

Igen, ezt tegnap keso ejjel mar en is megtalaltam, igazabol gyakorlatilag ugyan ezt is probaltam mar joval elobb, oszvissz annyit csesztem el hogy a lib teljes nevet adtam meg, igy libstatic.a helyett a linker liblibstatic.a-t keresett mert automatikusan elerakja a "lib"-et.
Masreszrol ez valamiert csak a statikus library eseteben mukodik, dynamic lybrary-nal valamilyen altalam ismeretlen okbol lemarad a stub generalas (.a) es csak a .so jon letre. Mondjuk amugy sem ertem hogy windozon mit szerencsetlenkedik a mingw .so-val es miert nem .dll-t gyart, de ez mar tenyleg egy olyan dolog ami ugy erzem nem igazan az en gondom kene legyen.

Most nincsen előttem Linuxos gép, de windows alatt mingw-vel annyi van, hogy a dll nevét kell megadni a kiterjesztés nélkül. Tehát, ha van egy ValamiFrankoLib.dll-ed, akkor -lValamiFrankoLib.

A második megjegyzésedhez annyit, hogy az általam felsorolt eszközök mind vannak és mennek windows alatt is, így nem vagy minden platformon ugyanahhoz az ide-hez kötve. Nekem ez azért fontos, mert az Eclipse C++ részét közel sem tartom a legjobbnak, sem windows sem linux alatt (nem is használom erre egyik alatt sem), és mást is használok a két helyen. Az tény, hogy kényelmes tud lenni az "egykattintásos" osztály és fájlbeillesztés a projektbe, de nekem többet ér, hogy ide-független build-om van mindkét platformon, ami megy parancssorból is.

A harmadikhoz annyit, hogy az valszeg Eclipse vagy beállítási gond, hogy .so-kat gyártat az *Eclipse*-d a mingw-vel, mert tud az dll-t is, ill. mint fentebb is írtam, nincsen szükség stub-ra (és ezt az eclipse készítői is tudják már). :)

Linux alatt annyi a difi, hogy a libValamiFrankoLib.so.1 -bol lesz -lValamiFrankoLib parameter.

Koszi, azt hiszem ugy 15-20 eve meg szuksegem lett volna arra az informaciora hogy mi a kulonbseg a statikus es dinamikus libek hasznalata kozott es melyiket hogyan kell elmeletileg hasznalni, de ez a kerdes nem errol szolt. Mindossze annyi a problemam, hogy hogyan vehetem ra az eclipse+cdt linkeret hogy az A project hasznalja (linkelje) a B project altal generalt libet.

Visual c++-ban ha jol emlekszem ehez eleg volt mindossze annyi, hogy a fuggosegeket beallitottam (A project fugg a B -lib- projecttol) - bar mar ott is jo ideje a #pragma comment( lib, ....) megoldast preferalom a library headereben, es az eclipse sajat dokumentacioja szerint fuggosegek beallitasa ott is eleg kellene hogy legyen, de nem az. Static libre mar megoldodott a dolog (lasd fentebb) dinamikus libre meg szerintem az az alapveto baj hogy maga a dynamic library project nem generalja le a stubot (.a) csak a dll-t (.so) igy a linker nem igazan tud mihez linkelni. Bar ha sskiss kkolleganak igaza van (es miert ne lehetne igaza) akkor 3.4.x-es gcc-tol mar a linker stub nelkul is kellene linkelje (gondolom legeneralja o a szukseges stubot), de erre ez eclipse szerintem meg se probalja ravenni.

na akkor a shared libes reszt megvalaszolom magam:

Eclipse shared library project nem gyartja le alapbol a stubot a dll-hez (.so)

jobbkatt a shared lib projecten, properties, a fabol c/c++build / settings kivalaszt
aztan GCC C++ linker alatt a Shared Library setting ala az import library name ala be kell irni a _teljes_ stub nevet ( esetemben libshared.a )

Ettol letrejon a stub, ami mar linkelheto.

Erdekesseg meg hogy win32-n a .so file az tulajdonkeppen teljesen szokvanyos win32 dll

hat mesem lesz ez ilyan ecceru ;)

ami win32-n es linuxon is mukodik ugyan ugy az a static library hasznalata.

linuxon valoban siman linkelheto a shared lib (.so) is import library nelkul, cserebe viszont a windozon az import library eloallitasahoz szukseges -Wl,--output-implib=... kapcsolot nem eszi a g++. Windozon viszont import library nelkul nem linkelheto maga a .so (dll)

Lásd izé.

The import library created by the "--out-implib" linker option is required iff (==if and only if) the DLL shall be interfaced from some C/C++ compiler other than the MinGW toolchain. The MinGW toolchain is perfectly happy to directly link against the created DLL.

Ha a dll-t a -no-undefined és --enable-runtime-pseudo-reloc paraméterekkel fordítod, akkor nem kell használni a dllexport/dllimport attributumokat sem, és import lib nélkül tudsz linkelni a futtathatóhoz a --enable-auto-image-base --add-stdcall-alias opciók használatával a linux alatti mókához hasonlóan.

Elvileg működnie kéne.
http://sourceware.org/binutils/docs-2.16/ld/WIN32.html

Itt azt írja, hogy külön kapcsoló nélkül működik, ha nem talál .a-t keres .dll-t...
Viszont ha neked az eclipse .so-t csinál, akkor szerencsétlen ld hiába keres .dll-t.

Az Eclipse-nek marhára nem .so-t kéne csinálnia...
Project Properties/"C/C++Build"/Settings/Build artifact-nál az extension dll?

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

ez volt az. Az artifacts-nal a az extension so alapallapotban shared library projectnel win32-n is. Atirva dll-re mar tudja linkelni. Koszonet mindenkinek aki segitett megoldani a problemat, maris konnyebben erzem magam a tudattol hogy nem feltetlenul a visual studio az egyetlen hasznalhato IDE c++-ra windozon sem.

Egyetlen apro szepseghiba zavarja meg az osszkepet, nevezetesen az, hogy ha az elkeszult .exe-t futtatni vagy debuggolni szeretnem, akkor vagy az ot tartalmazo konyvtarba vagy egy a path-en szereplo konyvtarba kell masoljam a dll-t (ami alapjaban veve ertheto, ezeken a helyeken keresi windows a dll-eket, visual studio nem tudom hogyan oldja meg, de ott ha egy dll projectet dependency-nek jelolok meg, megtalalja az eppen aktualis build confighoz tartozo leforditott dll-eket. Jo lenne ha lenne erre eclipse alatt valami megoldas vagy legalabb a megfelelo helyre masolast lenne jo automatizalni. )

Valahogy importálhattad a linuxos projectet, mert ha új shared lib projectet indítasz akkor az ott dll (legalábbis nálam).

Hirtelen 3 megoldási javaslatom van.
a) shared project/Project Properties/"C/C++Build"/Settings/Build steps/post-build steps
b) normal project/Project Properties/"C/C++Build"/Settings/Build steps/pre-build steps
c) normal project/Run/Open Run Dialog/Environment/Path

Szerintem a c a legtisztább legszárazabb érzés...

(Igen, jobb lenne ha ez menne magától... De bár ez lenne a legnagyobb gond a CDT-vel. :) )

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Idézet:
Valahogy importálhattad a linuxos projectet, mert ha új shared lib projectet indítasz akkor az ott dll (legalábbis nálam).

Ja, konnyen lehet hogy ez tortent, mivel ezzel parhuzamosan subclipse-szel is jatszottam, szoval siman belefer hogy linux alatt hoztam letre a dolgokat, betoltam svn-be, es win alatt csak kiszedtem.

Idézet:
Szerintem a c a legtisztább legszárazabb érzés...

Hat en az elso kettot preferalnam a kovetkezok miatt:

Tegyuk fel a project(ek)nek buildelhetonek es debuggolhatonak kell lenniuk win es linux alatt egyarant. Ez maskepp nem igazan oldhato meg mint kulon build konfiguraciokat csinalni windowsra es linuxra (linux alatt pl .so kell kepzodjon a shared lib forditasanal, win alatt meg .dll) Azaz van 2*2 build konfig ugyis (Debug/Release * Linux/Win32) itt post vagy pre build stepkent inditok a wines configokban egy batch, linuxos konfigokban egy shell script file-t ami az applikacio konyvtaraba vagy linux alatt olyan helyre ahol a dinamikus linker keresni fogja masolja a dinamikus libet. igy csak build konfiguraciot kell valtanom ha platformot valtok, semmi mas matatas nem kellhet elvileg.

Idézet:
(Igen, jobb lenne ha ez menne magától... De bár ez lenne a legnagyobb gond a CDT-vel. :) )

Nocsak. Meselj, hagy ne akkor rongyoljak bele az ennel nagyobb problemakba amikor elesben szeretnek valamit csinalni.

Ha már úgyis van két-két config, akkor mindegy, hogy a run environment-et írod át, vagy pre/post-build steps-t adsz meg. Legalábbis gondolom ezek ugyanott mentődnek (a .project file-ba). Kivéve ha tévedek. :)

Azt most nem kezdem részletezni, hogy mi van a VS-ben ami a CDT-ben nincs. :)
Én leginkább Qt-t használok, így lehet, hogy pár hiba a Qt plugin miatt van, de egyszerűen nem bírom rávenni, hogy Release-t fordítson, hiába állítgatom át. (Ilyenkor jön a parancssor.)

Ami nekem a legnagyobb szívfájdalom, az a kódkiegészítés. Nagy előrelépések történtek főleg sebesség terén, de még mindig kevéssé használható. A saját osztályaim tagjait még csak-csak megtalálja, de a libekét nem, pedig pont ez lenne fontos.

Még sorolhatnék ilyen idegesítő apróságokat...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o

Idézet:
Ha már úgyis van két-két config, akkor mindegy, hogy a run environment-et írod át, vagy pre/post-build steps-t adsz meg. Legalábbis gondolom ezek ugyanott mentődnek (a .project file-ba). Kivéve ha tévedek. :)

Nekem ugy tunt hogy ott nem nagyon akartak mukodni a relativ path-ek. Az meg messze nem garantalt hogy minden gepen ugyan oda fogom kicsekkolni.
De mind1, neked az a szimpatikusabb megoldas, nekem meg a masik ;) Izlesek es pofonok...

Idézet:
Én leginkább Qt-t használok, így lehet, hogy pár hiba a Qt plugin miatt van, de egyszerűen nem bírom rávenni, hogy Release-t fordítson, hiába állítgatom át. (Ilyenkor jön a parancssor.)

Ezzel meg egyutt birok elni... debugot tudjon forditani jol, meg debuggolni lehessen vele, rilzit ugyis jo esellyel ritkabban fordit az ember.

Idézet:
Ami nekem a legnagyobb szívfájdalom, az a kódkiegészítés. Nagy előrelépések történtek főleg sebesség terén, de még mindig kevéssé használható. A saját osztályaim tagjait még csak-csak megtalálja, de a libekét nem, pedig pont ez lenne fontos.

Hat igen, ez mar fajdalmasabb. Ha a fenti peldaban szereplo library projectet pl kiszedem a workspace-bol, az ott definialt osztalyra mar nem megy a kiegeszites. Erdekes modon az stl osztalyaira viszont mukodik. Van erre mar bugreport a cdt projectnel vajon?

Project properties/"C/C++ General"/Paths and Symbols/Includes/GNU C++ alatt elvileg hozzá lehet adni az include könyvtárakat. Nem tudom ez befolyásolja-e az indexert, de jobb ötletem nincs...

"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee."
-- Ted Ts'o