[C++]Hoe een externe C libary aanroepen vanuit C++

[GAEvakYD]

Ik ben bezig met een programma die screenshots pakt en die vervolgens die gemaakte shots in een buffer plaats(Gemaakt in C++). Van deze plaatjes wil ik dan een mpegstream maken. De code dat de shots maak heb ik zelf ontwikkeld, de code die van een reeks plaatjes een mpeg stream maakt heb ik van berkely. Dit omdat het maken van mpeg zo complex is(het gehele berkely project heeft iets van 50 C,H files).
Het mpeg's maken werkt perfecto wanneer ik er gewoon een binarie van maakt.

Het probleem is nu dat ik beide programma's in 1 workspace wil hebben in vc6. Dat ik vanuit mijn eigen programma gewoon die C functies kan aanroepen. Omdat mijn code C++ en de MPEG_files puur C geeft dit problemen.

Ik heb het geprobeerd dmv:

extern "C"
{
<headerfiles>
}

Maar dit blijft unresolved external linker errors geven :

- main.obj : error LNK2001: unresolved external symbol _mpeg_encode
- Debug/new.exe : fatal error LNK1120: 1 unresolved externals

Ik heb ook al geprobeerd door van mpeg_encode een hele library te maken, maar het blijft external linker errors geven.


Het C programma is http://www.buckosoft.com/gallery/tools/mpeg_encode/
(Mpeg encoder van Berkely)

Mocht het onduidelijk wezen dan moet je die source maar eens downloaden.

Alvast bedankt

Een jongen die hier al een week op vast zit.

[Soultaker]

Wat link je zoal mee? Gecompileerde broncode of een library?

_{Wat moet een MPEG encoder trouwens met PNG support?}

[bloody]

Soultaker schreef op 18 september 2002 @ 15:36:
Wat link je zoal mee? Gecompileerde broncode of een library?

_{Wat moet een MPEG encoder trouwens met PNG support?}

misschien zodat ie ook png plaatjes kan omzetten naar MPEG??? (duh)

[GAEvakYD]

Nou het was zo de orginele mpeg_encode van berkely was beschikbaar voor Windows OF voor Linux. Wij moeten een portable app maken, ik ging toen zoeken en toen kwam ik het hele project tegen van buckosoft, dat was al een VS6 project die simpel te porten was naar Linux/Unix/Windows. Maar dat PNG support gebruiken we dus helemaal niet.

We hebben gewoon 2 projecten in 1 workspace zitten, we roepen vanuit de 1 (de grabber) de ander aan (met de C files). We hebben het misschien wel onderschat maar moet toch kunnen. We dachten we slopen de main uit Mpeg_encode en zoiets gaan we nabootsen in een totale main voor beiden projecten.

[farlane]

Het is duidelijk dat hij de headers wel kan vinden, dus dat is goed.

Je moet alleen zorgen dat de betreffende C files ook worden meegecompileerd.

Of ...

Compileer je mpeg files naar een lib/dll en link met die lib/dll.

[Soultaker]

GAEvakYD schreef op 18 september 2002 @ 15:41:
We hebben gewoon 2 projecten in 1 workspace zitten, we roepen vanuit de 1 (de grabber) de ander aan (met de C files). We hebben het misschien wel onderschat maar moet toch kunnen. We dachten we slopen de main uit Mpeg_encode en zoiets gaan we nabootsen in een totale main voor beiden projecten.

Dat is een vrij primitieve vorm van libraries linken. Het zou in principe wel moeten kunnen. Worden de C files wel goed gecompileerd? En worden die niet stiekum met de C++ compiler gecompileerd, waardoor de symbol names anders zijn?

Controleer anders de symbol tables van object files even, om te zien of je de missende references misschien handmatig kan vinden.

bloody schreef op 18 september 2002 @ 15:38:misschien zodat ie ook png plaatjes kan omzetten naar MPEG??? (duh)

Dat lijkt me een nogal slecht ontwerp. Als je MPEG library een of andere standaardformaat kan coderen, dan kun je met een PNG library, die daar voor bedoeld is, de PNG plaatjes wel decoderen. Het is wel zo netjes om functionaliteit te scheiden en dus in aparte modules te stoppen.

[Verwijderd]

Soultaker schreef op 18 september 2002 @ 16:00:
[...]

Dat is een vrij primitieve vorm van libraries linken. Het zou in principe wel moeten kunnen. Worden de C files wel goed gecompileerd? En worden die niet stiekum met de C++ compiler gecompileerd, waardoor de symbol names anders zijn?

Controleer anders de symbol tables van object files even, om te zien of je de missende references misschien handmatig kan vinden.

[...]

Hoe bedoel je "Worden de C files wel goed gecompileerd?" ?
Afzonderlijk van ons C++ project compileren de C files perfect.
En dat symbol names probleem dat kun je toch achterhalen door dat extern "C" {} te gebruiken ?

[Verwijderd]

Hee, Ruald/Raymond, jullie ook hier?

Kennelijk zitten jullie nog steeds met hetzelfde probleem waarvan jullie in de groepsmeeting afgelopen maandag al melding maakten. En nee, ik heb geen idee waar het aan ligt.

Een collega.

Edit: zijn GAEvakYD en BDX nou Ruald en Raymond, of heeft een van jullie twee nicks?

[Verwijderd]

Verwijderd schreef op 18 september 2002 @ 18:07:
Hee, Ruald/Raymond, jullie ook hier?

Kennelijk zitten jullie nog steeds met hetzelfde probleem waarvan jullie in de groepsmeeting afgelopen maandag al melding maakten. En nee, ik heb geen idee waar het aan ligt.

Een collega.

Edit: zijn GAEvakYD en BDX nou Ruald en Raymond, of heeft een van jullie twee nicks?

Hee collega, ja wij ook hier

Nee ieder heeft een aparte nick...
Leuke webpagina trouwens

Leuk om hier collega's tegen te komen haha

[Verwijderd]

Om nog even wat constructiefs bij te dragen: ik neem aan dat jullie die suggestie die Luuk maandag deed al hebben geprobeerd? (even rommelen met de volorde van de libs die je meelinkt). Vogel even uit in welke lib die _mpeg_encode staat, en neem die lib ook als eerste mee in de lijst (niet verplaatsen, maar copieren in de lijst dus. verplaatsen kan altijd nog).

Enne, dit is misschien wel erg basic: weet je zeker dat je alle libs die in beide originele projekten staan, ook in het gecombineerde projekt hebt? Ik vraag het maar even, een foutje is zo gemaakt...

[Verwijderd]

Verwijderd schreef op 18 september 2002 @ 18:50:
Om nog even wat constructiefs bij te dragen: ik neem aan dat jullie die suggestie die Luuk maandag deed al hebben geprobeerd? (even rommelen met de volorde van de libs die je meelinkt). Vogel even uit in welke lib die _mpeg_encode staat, en neem die lib ook als eerste mee in de lijst (niet verplaatsen, maar copieren in de lijst dus. verplaatsen kan altijd nog).

Enne, dit is misschien wel erg basic: weet je zeker dat je alle libs die in beide originele projekten staan, ook in het gecombineerde projekt hebt? Ik vraag het maar even, een foutje is zo gemaakt...

Dat van Luuk hebben we inderdaad geprobeerd en dat heeft voor wat minder errors gezorgd inderdaad

Dat van die libraries kan ik niet met zekerheid zeggen, ik dacht het wel maar misschien dat Ruald het zeker weet. Morgenochtend even proberen

[Verwijderd]

Nou 'k hoor het morgen wel.

Nog iemand anders met suggesties voor deze jongens?

[madwizard]

GAEvakYD schreef op 18 september 2002 @ 15:34:
Maar dit blijft unresolved external linker errors geven :
- main.obj : error LNK2001: unresolved external symbol _mpeg_encode

Ik heb de source gedownload, een find in files gedaan op 'mpeg_encode', maar hij vindt het alleen terug in commentaar. Bestaat mpeg_encode wel ?

[Verwijderd]

madwizard schreef op 18 september 2002 @ 20:07:
[...]
Ik heb de source gedownload, een find in files gedaan op 'mpeg_encode', maar hij vindt het alleen terug in commentaar. Bestaat mpeg_encode wel ?

We hebben de mainfunctie even hernoemd naar mpeg_encode.
Om zo even te testen of het sowieso wel vanuit een programma lukt om die functies aan te spreken. mpeg_encode staat dus even gelijk aan de main..

[madwizard]

Als ik het mpeg_encode project gewoon compile zoals het is met de mapfile aan, komt main gewoon als symbol voor in main.obj:

code:

 0001:0000da50    _main            0040ea50 f   main.obj

Zou dus als je het hernoemt gewoon _mpeg_encode moeten zijn in main.obj... Heb je die gelinkt aan je eigen programma? Als je er al een lib van had gemaakt zou dat ook moeten werken.

edit:
Heb main hernoemd naar mpeg_encode, alles gecompiled, nieuw projectje gestart, mpeg_encode als extern "C" gedeclareerd en gelinkt aan alle .obj's uit het mpeg project (kan ook in een lib natuurlijk) + alle benodigde libs.

code:

extern "C" int mpeg_encode(int argc, char* argv[]);
int main(int argc, char* argv[])
{
    printf("Hello World!\n");
    mpeg_encode(argc, argv);
    return 0;
}

Het werkt:

code:

X:\dev\test\mpeg_encode\bla\Debug>bla
Hello World!
Usage:  mpeg_encode [options] param_file
         BuckoSoft build (with png support)
[...]

[GAEvakYD]

Potverdorie, Ga ik dat morgen ook eens even proberen. Bedankt alvast, we zaten hier al een tijdje op namelijk. Het is nu 23.22 en kom net uit mijn werk (avondwerk). Morgenvroeg 07.30 bezig ik met frisse moet.

Nogmaals

Thanks

[Verwijderd]

Ik krijg nog 2 external errors

Linking...
bitio.obj : error LNK2001: unresolved external symbol __imp__htonl@4
bitio.obj : error LNK2001: unresolved external symbol __imp__send@16
Debug/grabit.exe : fatal error LNK1120: 2 unresolved externals

Wat heb ik gedaan?

- libjpeg.lib, libpng.lib, zlib.lib toegevoegd aan het nieuwe project
- alle .obj files uit de Debug directory van mpeg_encode toegevoegd aan het nieuwe project

Er zijn al wel een heleboel linker errors weg.

[farlane]

Verwijderd schreef op 19 september 2002 @ 08:36:
Ik krijg nog 2 external errors

Linking...
bitio.obj : error LNK2001: unresolved external symbol __imp__htonl@4
bitio.obj : error LNK2001: unresolved external symbol __imp__send@16
Debug/grabit.exe : fatal error LNK1120: 2 unresolved externals

Wat heb ik gedaan?

- libjpeg.lib, libpng.lib, zlib.lib toegevoegd aan het nieuwe project
- alle .obj files uit de Debug directory van mpeg_encode toegevoegd aan het nieuwe project

Er zijn al wel een heleboel linker errors weg.

Lijkt erop dat je nog een winsock lib moet linken.

[GAEvakYD]

farlane schreef op 19 september 2002 @ 09:46:
[...]


Lijkt erop dat je nog een winsock lib moet linken.

Hmm das erg opmerkelijk, dit omdat die in het orignele project ook niet meegelinkt wordt. Hij doet het nu wel maar dat is toch een pure windows sock, dan is de app niet meer portable. Of is er ook zo'n soort lib voor Solaris en Linux?

[farlane]

GAEvakYD schreef op 19 september 2002 @ 09:52:
[...]


Hmm das erg opmerkelijk, dit omdat die in het orignele project ook niet meegelinkt wordt. Hij doet het nu wel maar dat is toch een pure windows sock, dan is de app niet meer portable. Of is er ook zo'n soort lib voor Solaris en Linux?

De winsock lib lijkt erg op de Berkeley socket libs.

[GAEvakYD]

farlane schreef op 19 september 2002 @ 09:57:
[...]


De winsock lib lijkt erg op de Berkeley socket libs.

We wilden graag gewoon de source van berkeley in staat houden, dit omdat we deze simpel kunnen porten en hiervan zeker weten dat het werkt zonder problemen.

Weet je niet waarom de orginele berkeley code niet om die winsock.lib vraagt?

[curry684]

farlane schreef op 19 september 2002 @ 09:57:
De winsock lib lijkt erg op de Berkeley socket libs.

Sterker nog, op ioctlsocket en fctl na zijn ze volledig identiek in de basis zolang je geen WSA*-functies gebruikt. En je moet even de includes ifdeffen...

Volgens mij kun je de verschillen tussen ioctlsocket en fctl zelfs met een define wegaliassen, parameters zijn geloof ik hetzelfde.

[farlane]

GAEvakYD schreef op 19 september 2002 @ 09:52:
[...]


Hmm das erg opmerkelijk, dit omdat die in het orignele project ook niet meegelinkt wordt. Hij doet het nu wel maar dat is toch een pure windows sock, dan is de app niet meer portable. Of is er ook zo'n soort lib voor Solaris en Linux?

Zie in bitio.c staan:

C:

/*==============*
 * HEADER FILES *
 *==============*/

#ifdef  _WIN32
#include "Winsock2.h"
#endif

#include <assert.h>
#include "all.h"
#include "byteorder.h"
#include "bitio.h"
#include "mtypes.h"

Dus je hebt winsock wel nodig.

[GAEvakYD]

Oeps, niet gezien. Nog 1 vraag dan zijn we eruit. Onder Windows werkt hij nu

We gingen hem proberen te runnen onder Linux, er zit alleen 1 foutje in. Bij het aanmaken van de o /libs files krijgen we de melding:

/usr/lib/crt1.o: In function `_start':
/usr/lib/crt1.o(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status
make: *** [mpeg_encode] Error 1
ordelman@castor$ ;5~

Daaruit concluderen wij dat hij een main verwacht, alleen die hebben we dus niet want die hebben we verplaatst naar het hoofdprogramma.

[farlane]

Als je de mpeg code nu als lib gebruikt moet je hem compileren naar een shared lib ( .o )

Daar zal een compilerswitch voor zijn. Hij is hier ook al wel eens voorbij gekomen dussuehh .... zoekt en gij zult vinden.

[Soultaker]

Je moet die bestanden alleen compileren en pas alles linken als je alle bestanden hebt die nodig zijn. Om te stoppen na het compileren kun je gcc de -c optie geven. Je krijgt dan alleen een aantal object files (.o) die je later mee kunt linken met je applicatie; dit zijn verder geen shared libraries of iets dergelijks.

[Verwijderd]

farlane schreef op 19 september 2002 @ 13:38:
Als je de mpeg code nu als lib gebruikt moet je hem compileren naar een shared lib ( .o )

Daar zal een compilerswitch voor zijn.

-c om precies te zijn

[Verwijderd]

ow shit je was me voor... wat fijn ook dat je hier je posts niet kan weghalen

[GAEvakYD]

Hmmmm, dat heb ik gedaan. Alleen hij blijft aan het einde nu zeuren om die main. Ik heb gewoon in die Makefile bij FLAGS -c geplaatst.

[Verwijderd]

hoe bedoel je bij FLAGS... waar gebruik je die FLAGS variabele? altijd en alleen bij de rules waar je die libs compileert?

[GAEvakYD]

Het is gewoon een meegeleverde Makefile van dat MPEG_ENCODE. Ps heb ik hier het genoegen met Theodoor????

[Soultaker]

GAEvakYD schreef op 19 september 2002 @ 15:43:
Hmmmm, dat heb ik gedaan. Alleen hij blijft aan het einde nu zeuren om die main. Ik heb gewoon in die Makefile bij FLAGS -c geplaatst.

Het wordt nu een beetje een Computer!Totaal howto; als je mijn verdere hulp op prijs stelt mag je wel wat meer eigen initiatief tonen en wat meer zelf proberen.

Ten eerste, moet dat niet CFLAGS of CXXFLAGS zijn? (Voor de C of C++ compiler). Verder, wat komt er op de command line te staan? Als er "gcc -c <bladiebla>" staat, zou het goed moeten staan. Ontbreekt die -c, dan wordt die optie blijkbaar niet meegegeven door make.

[Verwijderd]

GAEvakYD schreef op 19 september 2002 @ 15:54:
Het is gewoon een meegeleverde Makefile van dat MPEG_ENCODE. Ps heb ik hier het genoegen met Theodoor????

dan moet je ff kijken waar overal $(FLAGS) staat dat -c moet dan overal komen te staan waar je alleen .o files wil hebben... of je dat nou via $(FLAGS) doet of niet... dat maakt je compiler niet uit

enneuh natuurlijk heb je het genoegen met Theodoor, ken jij nog meer McMotion's dan?

[GAEvakYD]

Oke sorry jongens. Ik ga morgen weer met frisse moet aan de gang. Zoals jullie merken is compileren enzo onder linux / unix niet mijn sterkste aangelegenheid.

[Verwijderd]

neuh ik ook niet, maar je hebt er 2 handige faciliteiten voor... man, en de unix2 syllabus