[C++] ofstream geeft in combinatie met mysql een link error

[mduijvendijk]

Zoals de titel al aangeeft, krijg ik een link error als ik een ofstream gebruik.
Dit was niet het geval, toen ik nog geen MySql in mijn applicatie had geimplementeerd.

Ik krijg de volgende error:
libcpd.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol __CrtDbgReport
Debug/PFA.exe : fatal error LNK1120: 1 unresolved externals
Error executing link.exe.

Ik heb al op verschillende manieren de klasses geinclude, zonder resultaat.
Zodra ik de outStream.open regel uit zet, doet de applicatie het weer normaal:

code:

ofstream outStream;
outStream.open("c:\\html\\uitvoer.html");

Weet iemand een manier om toch ofstream te kunnen gebruiken?

[WildernessChild]

Denk dat je even moet kijken of je wel de juiste libraries meelinkt. Welke dat zouden moeten zijn kan ik je zo ook niet vertellen, maar dit is 9 van de 10 keer de oorzaak van "unresolved external"s.

[MSalters]

std:: vergeten, in combinatie met <fstream.h> ?

Tegenwoordig gebruik je <fstream> en std::ofstream

[mduijvendijk]

Of ik std::ofstream er nu wel of niet in zet, ik krijg altijd die link error.

[Surehand]

Geeft het nalezen van wat Google draadjes geen hint naar eventuele oplossingen?

[riezebosch]

Kijk eens in de MSDN onder _open.

Ik neem aan dat je ook Windesheim student bent, aangezien je app PFA heet in combinatie met MySQL? Wij hadden probleem met openen van files op de oude manier in combinatie met threads in blok 1.4. Toen ben ik op deze oplossing gestuit, en werkte het wel.

Met _open kan je een bestand openen:

C++:

int file = _open(filename, _O_BINARY|_O_WRONLY|_O_CREAT, _S_IREAD|_S_IWRITE);

De handle naar de file wordt bewaard in een int, met welke je weer operaties op de file uit kan voeren (in dit geval binair schrijven):

C++:

_write(file, (char *) &sPj, sizeof(sPrjAct));

Zoals ik al zei, kijk is in de MSDN

Routine
_open

Required Header
<io.h>

Optional Headers
<fcntl.h>, <sys/types.h>, <sys/stat.h>

Compatibility
Win 95, Win NT

[ Voor 20% gewijzigd door riezebosch op 26-01-2004 09:10 ]

[.oisyn]

Waarom zou je ineens lowlevel IO functies moeten gaan gebruiken Lijkt me een beetje onzin.

Nee, het lijkt mij meer een gemixte runtime probleem, waarbij je voor verschillende delen van je code verschillende runtimes gebruikt. Voor mysql de normale terwijl voor je eigen code de debug runtime bijvoorbeeld

[Verwijderd]

[...]

Ik krijg de volgende error:
libcpd.lib(xmbtowc.obj) : error LNK2001: unresolved external symbol __CrtDbgReport
Debug/PFA.exe : fatal error LNK1120: 1 unresolved externals

[...]

code:

ofstream outStream;
outStream.open("c:\\html\\uitvoer.html");

Die error is in elk geval te verklaren omdat de ofstream::open een functie nodig heeft uit "xmbtowc.obj" in de "libcpd.lib" library. Echter deze functie heeft op zijn buurt blijkbaar "__CrtDbgReport" nodig en dat symbool kan de linker niet in de meegelinkte libraries vinden. Dit symbool/deze functie zal dus waarschijnlijk te vinden zijn in een van de libraries die je niet meelinkt. Je zou ze 1 voor 1 uit kunnen proberen tot het wel linkt.

In principe kan het trouwens geen kwaad om zo veel mogelijk libraries mee te linken, de linker is altijd zo slim om alleen die bestanden op te halen die echt nodig zijn voor het maken van je applicatie. Het linken duurt alleen langer...

[.oisyn]

DaZaffiro: _CrtDebugReport is een C runtime functie die zich alleen bevindt in de debug runtime. Alle libraries meelinken (dus alle runtimes) lijkt me niet echt verstandig

Hij bevindt zich als het goed is in libcd.lib, wat de single-threaded release C run-time is. Ik vermoed dat hiermee gelinkt wordt, terwijl voor de C++ runtime libcpd.lib gebruikt wordt, wat een debug runtime is.

mduijvendijk: kun je eens je project settings hier posten? Denk daarbij aan wat voor build je doet (debug of release), welke libraries en welke runtime je gebruikt
.edit: oh, ik bedenk me ineens wat. Ga naar je linker settings, en voeg handmatig aan de command-line toe: /VERBOSE:LIB. Build dan je programma en post de output hier als je wilt

[ Voor 14% gewijzigd door .oisyn op 27-01-2004 15:31 ]

[riezebosch]

.oisyn schreef op 27 januari 2004 @ 14:26:
Hij bevindt zich als het goed is in libcd.lib, wat de single-threaded release C run-time is. Ik vermoed dat hiermee gelinkt wordt, terwijl voor de C++ runtime libcpd.lib gebruikt wordt, wat een debug runtime is.

Aha, dan was dat zeker ook ons probleem (zoals aangegen in m'n vorige post) met ons programma, toen we onze applicatie uitbreidden naar multi-threaded gaf dat conflicten met ofstream... (of slaat dit nergens op )
En .oisyn, wat is er dan onzin om de lowlevel-functies te gaan gebruiken? Wat is überhaupt het grote verschil (zit al te lezen op online-mdsn)?

[.oisyn]

Dat slaat wel ergens op ja, het zijn typisch fouten van het mixen van verkeerde runtimes, zoals ik in mijn eerste post in deze draad zei. Meestal geeft dit trouwens wel linker warnings trouwens hoor, iets over "incompatible runtime versions" oid

Er is natuurlijk niets mis met low-level IO, dat gebruiken is ook niet onzin, mits je het nodig hebt natuurlijk. Wat ik juist onzin vond is dat als de C++ iostreams niet werken dat je dan ineens lowlevel IO gaat gebruiken. Dat is symptoombestrijding . In jullie geval was het blijkbaar nog wel te doen, maar stel nou dat je hele applicatie al is gebouwd, gebruik makend van de iostreams (wat sowieso een aanrader is als je C++ programmeert, het is een generieke manier om streams te representeren die je makkelijk zelf uit kunt breiden), en dan blijkt het op het laatste moment ineens niet te werken. Ga je dan al je code omzetten om gebruik te maken van die lowlevel io functies, zonder dat je daadwerkelijk weet wat nou precies het probleem is? Het lijkt me dan handiger om even uit te zoeken wat er dan verkeerd gaat, want je moet de C++ iostreams toch wel gewoon kunnen gebruiken icm mysql?

Wat was trouwens de reden dat je voor de niet-ISO (wel POSIX trouwens, maar je gebruikt een underscore ervoor. De varianten zonder underscore werken ook gewoon, tenzij je compiled met de strict ANSI optie) lowlevel IO functies koos, en niet gewoon van de ISO C stream functies als fopen () en fread () en aanverwanten?

Ik bedenk me overigens ineens nog een manier om dit te checken, ik edit het er even bij in mijn vorige post

[riezebosch]

Linking code compiled with /MT with the library LIBC.lib causes LNK2001 on _beginthread, _beginthreadex, _endthread, and _endthreadex.

Volgens mij (is inmiddels 3 jaar geleden hoor) hadden wij juist die optie nodig in de app voor de ofstream ofzo, en dan gaf ie dus ook een LNK2001 voor de thread...

[Verwijderd]

.oisyn schreef op 27 januari 2004 @ 14:26:
DaZaffiro: _CrtDebugReport is een C runtime functie die zich alleen bevindt in de debug runtime. Alle libraries meelinken (dus alle runtimes) lijkt me niet echt verstandig

offtopic:
Ik zit hier al een tijdje over te peinzen, maar als ik alle runtime libraries mee geef, dan "linkt" de linker toch alsnog alleen maar die runtimes mee die nodig (kunnen) zijn? Alleen bij runtimes komt er in de portable executable te staan welke runtimes er geladen moeten worden en bij statische libs worden de de functies uit de libraries statisch mee gelinkt?

Je hebt dan een overhead aan overige functies uit elke runtime die je niet gebruikt in het geheugen geladen, maar als je helemaal niets uit een runtime nodig zou kunnen hebben, wordt deze toch ook niet in het lijstje gezet van te laden libraries in je executable? Of heb ik altijd het linken van runtimes verkeerd begrepen, dat zal dan dus wel...

[.oisyn]

Nee, wat je zegt klopt wel, alleen zit je met dubbele symbols. Neem bijvoorbeeld libc.lib en libcd.lib, een release en een debug lib. Het gros van alle functies die hierin zitten komen overeen. Hoe bepaalt de linker dan welke hij moet hebben? Ik vermoed een warning, tenzij hij gewoon degene pakt die ie als eerst tegenkomt, maar dan bevind je je dus op enorm glad ijs

[Verwijderd]

.oisyn schreef op 27 januari 2004 @ 16:51:
Nee, wat je zegt klopt wel, alleen zit je met dubbele symbols. Neem bijvoorbeeld libc.lib en libcd.lib, een release en een debug lib. Het gros van alle functies die hierin zitten komen overeen. Hoe bepaalt de linker dan welke hij moet hebben? Ik vermoed een warning, tenzij hij gewoon degene pakt die ie als eerst tegenkomt, maar dan bevind je je dus op enorm glad ijs

Pfiew, dus het was toch als ik tot nog toe dacht.. /me DaZaffiro linkt altijd met meer libraries dan nodig...
Maar inderdaad, of alleen de runtimeversies, of de statische.. Zou ik ook nooooit andes doen.

Volgens mij zoekt de linker net zolang naar een symbool, totdat 'ie deze vindt en gaat dan niet verder... Maar dat kan een aardige zooi worden, afhankelijk van de volgorde van de opgegeven libraries Wordt alleen maar linker