[C++ Builder] Linker error o.a. bij strlen()

[Verwijderd]

Tijdens het linken van een m'n programma (= een DLL) krijg ik linker errors (unresolved external) bij standaard dingen zoals strlen(), strncpy(), sprintf(), enz.. string.h en stdio.h worden geinclude. Waar kan dit aan liggen ?

[Verwijderd]

Dan mist ie wat libraries

[Verwijderd]

Libs en include files staan nog allemaal op de plek waar ze moeten staan en altijd al gestaan hebben

[Verwijderd]

Dat ze er staan houd nog niet direct in dat ie ze meelinkt

[Verwijderd]

Daar kan ik even niets tegenin brengen

Inmiddels alle instellingen wederom langsgegaan. Include path klopt, enz..

edit:
Onderstaande komt uit de helpfile. Krijg geen error message hierover, dus builder kan de includes wel vinden.

The <header_name> version specifies a standard include file; the search is made successively in each of the include directories in the order they are defined. If the file is not located in any of the default directories, an error message is issued.

[Verwijderd]

De hele DLL teruggebracht naar dit en krijg nog steeds de betreffende error:

[LinkerError] Unresolved external 'sprintf' referenced from PROGPATH.OBJ.

code:

#include <vcl.h>
#include <stdio.h>

extern "C" __declspec(dllexport) void TestFunctie();

int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void*)
{
    return 1;
}

__declspec(dllexport) void TestFunctie()
{
    char hierin[32];
    char stringetje[] = "Testing";

    sprintf(hierin, "%s deze pruttel", stringetje);
}

Heb overigens ook C++ Builder al opnieuw geinstalleerd om te zien of het daar aan lag, maar dat heeft ook niets geholpen. Andere programma's builden werkt gewoon goed, dus het is iets specifieks met bovenstaande code.

[Creepy]

Hmmm.. als C++ Builder net zo werkt als Delphi, dan op sprintf gaan staan en op F1 drukken, dan krijg je de help en zie je in welke header file die ziet..

Maar goed.. dan had ie volgens mij nog steeds in stdio.h moeten zitten... hmm..

[farlane]

Het is geen fout met de headers maar met de libs. Check je linker en lib pad en je linker instellingen.

[MSalters]

Op donderdag 10 januari 2002 23:52 schreef Zotty het volgende:
Tijdens het linken van een m'n programma (= een DLL) krijg ik linker errors (unresolved external) bij standaard dingen zoals strlen(), strncpy(), sprintf(), enz.. string.h en stdio.h worden geinclude. Waar kan dit aan liggen ?

De symbols komen uit de C library. Nou kun je er van uit gaan dat de C library als DLL beschikbaar is, of 'm statisch meelinken in je DLL.
In het eerste geval klaagt C++Builder over het feit dat je niet vertelt dat je de C library als DLL gebruikt, in het tweede geval dat je niet vertelt dat ie de C library mee moet linken.
Oh , programma != DLL. Als je dus een nieuwe DLL maakt voor een bestaand programma, heb je de keus tussen C-library in DLL en C-library statisch gelinkt misschien niet. Als het
programma statisch linkt, of een MSVC C-library DLL gebruikt, dan moet jij statisch linken.

[Verwijderd]

Dat de juiste includes gebuikt worden heb ik gecontroleerd door de betreffende .h file te openen en op zoek te gaan naar de betreffende 'functie'. Dan lijkt me dat je er van uit mag gaan dat #include <xxxxx.h> de juiste file is. Bovendien genereerd builder een foutmelding als je de verkeerde pakt.

Path instellingen e.d. kloppen ook allemaal. Zoals ik al zei kan ik andere programma's gewoon builden zonder problemen, ook als dezelfde includes gebuikt worden.

Het moet dus iets zijn in het programma/DLL zelf.

[Verwijderd]

Het ligt dus aan "__declspec(dllexport)" Haal je dat weg, werkt alles perfect...... even afgezien van het feit dat de DLL dan waardeloos is geworden omdat je je functies niet naar buiten kan exporteren...

[Verwijderd]

Wil iemand even testen of het werkt in VC++ oid? Als het dan namelijk wel werkt schop ik acuut Builder van m'n HD.

[Verwijderd]

*kick*

Wie wil bovenstaande code ff testen met VC++ ?

[Verwijderd]

Begin maar met trappen want compileerd prima , het enige wat ik moest doen is die include van vcl.h ff naar windows.h zetten want vc kent die borland vcl meuk niet.

[Verwijderd]

Op vrijdag 11 januari 2002 12:35 schreef Zotty het volgende:
Het ligt dus aan "__declspec(dllexport)" Haal je dat weg, werkt alles perfect...... even afgezien van het feit dat de DLL dan waardeloos is geworden omdat je je functies niet naar buiten kan exporteren...

Nu vind ik dat declspec toch al niet al te prettig werken, maak normaal gesproken gewoon een .def file aan voor m'n dll's is iets meer werk maar je hebt dan op 1 centrale plek staan wat er in je dll terecht komt en wat niet..

[farlane]

Probeer het eens dmv een .def bestand. Dan hoef je die __decspec(dllexport) niet te gebruiken.

[Verwijderd]

Bedankt voor het testen! Dan weet ik iig dat het niet aan de code ligt

'k heb geen idee wat een .def file is, maar dat valt zo op te zoeken. Het is weekend, dus tijd zat om daar eens naar te kijken. Als dat ook niet wil, gaat het *schop* dag Builder...
Baal er wel een beetje van dat Builder niet wil meewerken, moet er voor school ook een heleboel mee doen en had gehoopt hobby en studie te combineren. Maar in dit geval gaat een werkende DLL voor gemak.

Bedankt voor de tip allebei

edit: typo

[curry684]

Ik weet niet wat jij hebt gedaan, maar ik heb net in BCB5 even op New geklikt, de 'DLL wizard' gekozen, een VCL Dll gevraagd en jouw routine erin gekopieerd. Werkt als een tiet...

De totale code:

code:

//---------------------------------------------------------------------------

#include <vcl.h>
#include <windows.h>
#include <stdio.h>
#pragma hdrstop
//---------------------------------------------------------------------------
//   Important note about DLL memory management when your DLL uses the
//   static version of the RunTime Library:
//
//   If your DLL exports any functions that pass String objects (or structs/
//   classes containing nested Strings) as parameter or function results,
//   you will need to add the library MEMMGR.LIB to both the DLL project and
//   any other projects that use the DLL.  You will also need to use MEMMGR.LIB
//   if any other projects which use the DLL will be performing new or delete
//   operations on any non-TObject-derived classes which are exported from the
//   DLL. Adding MEMMGR.LIB to your project will change the DLL and its calling
//   EXE's to use the BORLNDMM.DLL as their memory manager.  In these cases,
//   the file BORLNDMM.DLL should be deployed along with your DLL.
//
//   To avoid using BORLNDMM.DLL, pass string information using "char *" or
//   ShortString parameters.
//
//   If your DLL uses the dynamic version of the RTL, you do not need to
//   explicitly add MEMMGR.LIB as this will be done implicitly for you
//---------------------------------------------------------------------------

#pragma argsused
int WINAPI DllEntryPoint(HINSTANCE hinst, unsigned long reason, void* lpReserved)
{
  return 1;
}

extern "C" __declspec(dllexport) void TestFunctie();

__declspec(dllexport) void TestFunctie()
{
    char hierin[32];
    char stringetje[] = "Testing";

    sprintf(hierin, "%s deze pruttel", stringetje);
}

//---------------------------------------------------------------------------

[Verwijderd]

Inmiddels gebruik ik C++ Builder 5 (trial ) en het hele probleem is als sneeuw voor de zon verdwenen

Moraal van het verhaal; gebruik nooit C++ builder 3..

[Verwijderd]

RHAAAAAAAAAAAAAA, kl*te builder! Versie 5 zelfde verhaal.

Het hele probleem wordt dus veroorzaakt doordat ik generate underscores uitzet. Staat het aan, dan linked alles goed, staat het uit, dan krijg je de linker errors

edit:
in de helpfile van versie 5 staat deze sneaky regel;

Underscores for C and C++ are optional, but you should turn this option on to avoid errors if you are linking with the Borland C++ libraries.

Zouden libraries van bijv VC++ te gebruiken zijn?

[curry684]

Op zondag 13 januari 2002 15:49 schreef Zotty het volgende:
Het hele probleem wordt dus veroorzaakt doordat ik generate underscores uitzet. Staat het aan, dan linked alles goed, staat het uit, dan krijg je de linker errors

Wat voor fantastisch goede reden heb je dan om ze uit te zetten?

Default settings veranderen voor redistributables is vragen om incompatibility...

[Verwijderd]

Op zondag 13 januari 2002 22:43 schreef curry684 het volgende:

[..]

Wat voor fantastisch goede reden heb je dan om ze uit te zetten?

Default settings veranderen voor redistributables is vragen om incompatibility...

Ik ben bezig met een winamp plugin en winamp kijkt naar 3 functies in je software. Deze 3 functies hebben vaste namen (init(), config() en quit()) en als je daar van afwijkt, doet winamp niks met je plugin.
Staan die underscores aan, dan komt in de DLL bijv. een _init() functie te staan. En dat werkt dus niet want winamp kan geen init() functie vinden. Om die reden moeten die underscores dus uitgeschakeld zijn.

[curry684]

Op zondag 13 januari 2002 23:59 schreef Zotty het volgende:
Ik ben bezig met een winamp plugin en winamp kijkt naar 3 functies in je software. Deze 3 functies hebben vaste namen (init(), config() en quit()) en als je daar van afwijkt, doet winamp niks met je plugin.
Staan die underscores aan, dan komt in de DLL bijv. een _init() functie te staan. En dat werkt dus niet want winamp kan geen init() functie vinden. Om die reden moeten die underscores dus uitgeschakeld zijn.

Heb je dat geprobeerd? Als in die 'Generate Underscores' functie slaat dacht ik enkel op de C++ name mangling, en daar je die functie als extern "C" exporteert heb je daar al sowieso geen last van. Ennuh ik pluk hier uit de Borland C++ documentatie de volgende regel:

Note:If you use _export or __export to export a function, that function will be exported by name rather than by ordinal (ordinal is usually more efficient).

Oftewel die interne mangled naam met underscore boeit geen hol volgens mij.

ps. __export is de oude versie van __declspec(dllexport) btw

* curry684 heeft overigens nog nooit een DLL geschreven die zonder libje werkte dus kan hier best zitten te zwammen.

[Verwijderd]

Op zondag 13 januari 2002 23:59 schreef Zotty het volgende:
Ik ben bezig met een winamp plugin en winamp kijkt naar 3 functies in je software. Deze 3 functies hebben vaste namen (init(), config() en quit()) en als je daar van afwijkt, doet winamp niks met je plugin.

Winamp kijkt alleen naar winampVisGetHeader hoor?

[Verwijderd]

Op maandag 14 januari 2002 00:19 schreef curry684 het volgende:
* curry684 heeft overigens nog nooit een DLL geschreven die zonder libje werkte dus kan hier best zitten te zwammen.

Heb al van alles geprobeerd, dus ik zou zeggen ja

Op maandag 14 januari 2002 00:27 schreef Yarvieh het volgende:

[..]

Winamp kijkt alleen naar winampVisGetHeader hoor?

Maakt voor dit probleem niets uit waar Winamp naar kijkt. Heb ook hiermee geexperimenteerd, wederom zonder positief resultaat.

[Verwijderd]

curry kan jij es kijken of je een van de standaard samples gecompileerd krijgt?

http://ftp.winamp.com/winamp/nsdn/vis_minisdk.zip

[Verwijderd]

De oplossing !!! 100% tested

Laat builder fijn underscores generaten en pas de volgende truuk toe;

Maak een module definition file (.def file) en zet daar het volgende in:

code:

LIBRARY GEN_TEST.DLL
EXPORTS
winampGetGeneralPurposePlugin = _winampGetGeneralPurposePlugin

Deze code zorgt ervaar dat na het compilen, maar voor het linken de underscore voor _winampGetGeneralPurposePlugin wordt weggehaald, waardoor winamp de DLL herkent als plugin. Verder worden alle underscores in takt gelaten zodat de rest van de source ook nog goed linked.

/me is nu ontzettend blij en opgelucht !!!!

[Verwijderd]

gelukkig riepen we gister middag pas dat je een def moest maken...

[Verwijderd]

Op maandag 14 januari 2002 01:49 schreef Yarvieh het volgende:
gelukkig riepen we gister middag pas dat je een def moest maken...

Ok, nu voel ik me echt heel stom En terecht!

Wil iemand me please een hele grote schop onder m'n kont geven!? Ik heb er niet meer aan gedacht na m'n reply van gister over de def file

[farlane]

*schop* (onder je kont that is)

NB Ga je je icontekst nu ook weer aanpassen?

[Verwijderd]

Op maandag 14 januari 2002 09:17 schreef farlane het volgende:
*schop* (onder je kont that is)

NB Ga je je icontekst nu ook weer aanpassen?

AUW! Dank je

Aangepaste icontekst wordt nog over nagedacht. Zodra de koffie klaar en opgedronken is