Page 2 of 2
Posted: Sat Jul 01, 2006 1:57 pm
by inc.
Im using "Import" in PB to access/link my resulted lib file out of VS C++ Express 2005.
On Win2000 the compiled PB codes do run ok, but the problems do continue ...
I installed WinXP for testing purposes on a diff. partition.
Now when I do start the PB resulted executable i compiled under Win2000 in WinXP I get a message that MSVCR80.dll is missing. Ok, I copied that dll into the system32 of xp but then I get a Runtime linking error when starting to cimpile my PB code.
I installed Visual C++ Express 2005 in WinXP and did compile the static lib file again.
Now ... I get this error:
If I do compile my c++ code as dll and and using the resulted lib by "import" then no problem ... so I only have problems when compiling a static lib under VS Express C++ for PB's "Import" purposes.
Posted: Sat Jul 01, 2006 5:56 pm
by KarLKoX
Go to your project settings --> Linker --> Manifest File --> Generate Manifest File = "No".
Hope it helps
Posted: Sat Jul 01, 2006 6:30 pm
by inc.
Sorry, Im doing a "static lib" and so VS Express doesnt show me any Manifest or linker options
Posted: Sat Jul 01, 2006 6:34 pm
by KarLKoX
Mmmh ... try exporting the makefile and remove the "/MANIFESTFILE:" switch ?
Posted: Sat Jul 01, 2006 7:47 pm
by inc.
I didnt find where to set exporting the makefile in VSC++ 2005 Express.
Meanwhile I installed VC6 .... and no Problems!
Created a "static library" project (as in VS2005), added my .cpp and .h files, also embedded the (much smaller than the VS2005 one) msvcrt.lib from the VC6 lib folder in the project (as in Vs2005) and xxxx.lib including the msvcrt.lib resulted.
I did link to that resulted lib out of VC6 via "import/endimport" in my PB code .... and everything works like a charm!
So same approach/procedure in both environments (VS2005 and VS6) but only the one resulted from VS6 works well.
Well ... maybe cause I got an install of VS6 now on my disk which maybe did add some needed stuff to my system32 ... which the final user maybe wont have
So the stuff resulted from VS2005 does end up in C runtime errors which even do occur if the msvcr80.dll is in place. I dunno why but it seems that M$ clearly did a hughe change on that.
Posted: Sun Jul 02, 2006 1:23 am
by KarLKoX
I continue to use vc6 when i want to create a static link (always with a .desc file) for the same reason but for DLL, VS2005 is far more better (in performance).
VS2005 is a major version optimised for .NET and CLR runtime though i think this is why it is more and more difficult to keep retrocompatibility.
Posted: Sun Jul 02, 2006 4:31 pm
by inc.
KarLKoX wrote:I continue to use vc6 when i want to create a static link (always with a .desc file)
Also my opinion. Since PB 4.0 I always use .def files when compiling the c++ codes and link the static libs using "Import/EndImport". For my personal purposes I went away from the PB Userlib concept and instead of that I go the static lib way. Also when I do access dynamic linked libraries ... no more Callfunction/Callfunctionfast as here also I do go the Import/EndImport way IF the wrapper lib file of the dll is present.
I heared somewhere that even if the dll comes as standalone its possible to generate a wrapper lib for that one using special tools. Can that be done via MinGW's BuildLib or whatever? IMHO thats the way MinGW accesses the WinAPI dlls in the Windows system, correct?
VS2005 is a major version optimised for .NET and CLR runtime though i think this is why it is more and more difficult to keep retrocompatibility.
Even if I do not use NET related things in my c++ code?
However I got both NET env's installed on my WinXP system (1.1 and 2.0) which doesnt prevent my VS2005 approach producing the trouble mentioned above.
but for DLL, VS2005 is far more better (in performance).
Yupp, dlls do work without problems on both env's VS2005 C++ and VC6.
PS: The funny thing is that I just recognised that I did compile my static lib without a def file so a lib file using the extern C stdcall smbol names resulted. Here you can see the symbol names within my resulted "AvsSupport.lib":
Code: Select all
-export:_avs_init@0 -export:_avs_exit@0 -export:_avs_create_env@0 -export:_avs_open_file@12 -export:_avs_open_script@12 -export:_avs_getvframe@12 -export:_avs_getaframe@28 -export:_avs_close@8 -export:_avs_destroy_env@4 -export:_avs_getlasterror@8 -export:_avs_getlasterror_CRLF@8
(the msvcrt.lib also was "embedded" while compiling, means only +250kb and so no other dependencies for future usage in PB))
In my PB code I used the following part to use that lib:
Code: Select all
Import "I:\Programme\PureBasic\Sources\AvsSupport_lib_VS6\Release\AvsSupport.lib"
avs_init()
avs_exit()
avs_close(pScriptEnvironment.l, clip_num.l)
avs_create_env()
avs_destroy_env(pScriptEnvironment.l)
avs_getaframe(pScriptEnvironment.l, clip_num.l, pbuf.l, start.q, count.q)
avs_getlasterror(pChar.l,len.l)
avs_getlasterror_CRLF(pChar.l,len.l)
avs_getvframe(pScriptEnvironment.l, clip_num.l, frame.l)
avs_open_file(pScriptEnvironment.l, pChar.l, VideoInfo.l)
avs_open_script(pScriptEnvironment.l, pChar.l, VideoInfo.l)
EndImport
So as you can see no Aliases using "AS" where used
but it worked anyway without "unreferenced symbol" errors!
Did Fred implement some symbol recognising stuff in PB4's Import Routines?
Posted: Sun Jul 02, 2006 6:54 pm
by KarLKoX
"I heared somewhere that even if the dll comes as standalone its possible to generate a wrapper lib for that one using special tools. Can that be done via MinGW's BuildLib or whatever? IMHO thats the way MinGW accesses the WinAPI dlls in the Windows system, correct? "
Yes, you can use dlltool to generate either a .lib or a .def file out of a dll.
VS2005 is a major version optimised for .NET and CLR runtime though i think this is why it is more and more difficult to keep retrocompatibility.
"Even if I do not use NET related things in my c++ code?"
It depend on your projet settings, by default, it is enabled.
The Import/EndImport is a good feature, i think Fred resolve the symbol (decorated or not, aliased or not and so on).
Btw, i always add msvcrt.lib inside the project, this resolve, in fact, a lot of pb link error.
Posted: Sun Jul 02, 2006 8:43 pm
by inc.
It depend on your projet settings, by default, it is enabled.
Do you now where to alter these NET and CLR Runtime related things in VS2005Express's settings?
Posted: Mon Jul 03, 2006 8:54 am
by KarLKoX
You will have first to check if CLR mode is activated :
Code: Select all
#ifdef __cplusplus_cli
String ^ str = gcnew String("C++/CLI string");
#else
String* str = new String(S"oldSyntax string");
#endif
Then, just check that the "/lcr" switch is not present in the linker commandline.
Posted: Mon Jul 03, 2006 11:04 am
by inc.
Merci!
Ill try that this evening
Posted: Mon Jul 03, 2006 8:52 pm
by KarLKoX
Mmhh ... this is the first time i get linker's errors with a static link lib i use : all my functions are exported but the linker complains about an unresolved symbol but i am sure @ 100 % that the function is well exported.
I did use ImportC/EndImport and it works well, didn't this already happen to you ?
Posted: Tue Jul 04, 2006 11:33 am
by inc.
Then, just check that the "/lcr" switch is not present in the linker commandline.
I do not see any specific "Linker" options when compiling a "static lib project" no matter which environment I do use (DevC++, VSC++2005, VC6).
So this means that also I cant set any linker switches in the resulted commandline. I do only see the approach to embedd dependand libraries by importing such lib's into the project.
... all my functions are exported but the linker complains about an unresolved symbol but i am sure @ 100 % that the function is well exported.
I did use ImportC/EndImport and it works well, didn't this already happen to you ?
For PB purposes I never export functions using Cdecl calling convention. I always use the way of "... extern C ... __stdcall ... " instead .
So as all my functions are exported as explained above I also do set within the compiler option the generic calling convention setting to "stdcall" instead of "cdecl". By this I never got Problems .... well at least in these cases
PS: The easiest workout for PB static lib generation to me seems to be the usage of DevC++.
But as in my case above "Avisynth" related code needs to be compiled using M$ Compilers, I do have to go the VC6 way at least in this case.
Posted: Tue Jul 04, 2006 2:48 pm
by KarLKoX
What i do is exporting the makefile and i do the tweak there, here is a makefile for a snes emulator i use and compile myself :
CC = cl
CFLAGS = /nologo /O2 /EHsc /wd4996
OBJS = main.obj \
libstring.obj libconfig.obj \
reader.obj cart.obj \
memory.obj bmemory.obj \
cpu.obj bcpu.obj \
apu.obj bapu.obj \
bdsp.obj \
ppu.obj bppu.obj \
snes.obj \
srtc.obj sdd1.obj c4.obj \
adler32.obj compress.obj crc32.obj deflate.obj gzio.obj inffast.obj \
inflate.obj inftrees.obj ioapi.obj trees.obj unzip.obj zip.obj zutil.obj \
jma.obj jcrc32.obj lzmadec.obj 7zlzma.obj iiostrm.obj inbyte.obj lzma.obj winout.obj
LIBS = kernel32.lib user32.lib gdi32.lib comdlg32.lib ddraw.lib dsound.lib dinput8.lib dxguid.lib
all: $(OBJS)
rc /r /fobsnes.res bsnes.rc
$(CC) /Febsnes.exe $(CFLAGS) $(OBJS) bsnes.res $(LIBS)
#/link /PGD:bsnes.pgd /LTCG:PGINSTRUMENT
clean:
del *.obj
del *.pgd
del *.pgc
del *.ilk
del *.pdb
######################
### win32-specific ###
######################
main.obj: *.cpp *.h video/* audio/* input/* ../config/*
$(CC) $(CFLAGS) /c main.cpp
#################
### libraries ###
#################
libstring.obj: ../lib/*.cpp ../lib/*.h
$(CC) $(CFLAGS) /c ../lib/libstring.cpp
libconfig.obj: ../lib/*.cpp ../lib/*.h
$(CC) $(CFLAGS) /c ../lib/libconfig.cpp
##############
### memory ###
##############
memory.obj: ../memory/memory.cpp ../memory/memory.h
$(CC) $(CFLAGS) /c ../memory/memory.cpp
bmemory.obj: ../memory/bmemory/*
$(CC) $(CFLAGS) /c ../memory/bmemory/bmemory.cpp
###########
### cpu ###
###########
cpu.obj: ../cpu/*.cpp ../cpu/*.h
$(CC) $(CFLAGS) /c ../cpu/cpu.cpp
bcpu.obj: ../cpu/bcpu/*
$(CC) $(CFLAGS) /c ../cpu/bcpu/bcpu.cpp
###########
### apu ###
###########
apu.obj: ../apu/*
$(CC) $(CFLAGS) /c ../apu/apu.cpp
bapu.obj: ../apu/bapu/*
$(CC) $(CFLAGS) /c ../apu/bapu/bapu.cpp
###########
### dsp ###
###########
bdsp.obj: ../dsp/bdsp/*
$(CC) $(CFLAGS) /c ../dsp/bdsp/bdsp.cpp
###########
### ppu ###
###########
ppu.obj: ../ppu/*.cpp ../ppu/*.h
$(CC) $(CFLAGS) /c ../ppu/ppu.cpp
bppu.obj: ../ppu/bppu/*
$(CC) $(CFLAGS) /c ../ppu/bppu/bppu.cpp
#################
### utilities ###
#################
reader.obj: ../reader/*.cpp ../reader/*.h
$(CC) $(CFLAGS) /c ../reader/reader.cpp
cart.obj: ../cart/*.cpp ../cart/*.h
$(CC) $(CFLAGS) /c ../cart/cart.cpp
############
### snes ###
############
snes.obj: ../snes/*.cpp ../snes/*.h
$(CC) $(CFLAGS) /c ../snes/snes.cpp
#####################
### special chips ###
#####################
srtc.obj: ../chip/srtc/*.cpp ../chip/srtc/*.h
$(CC) $(CFLAGS) /c ../chip/srtc/srtc.cpp
sdd1.obj: ../chip/sdd1/*.cpp ../chip/sdd1/*.h
$(CC) $(CFLAGS) /c ../chip/sdd1/sdd1.cpp
c4.obj: ../chip/c4/*.cpp ../chip/c4/*.h
$(CC) $(CFLAGS) /c ../chip/c4/c4.cpp
############
### zlib ###
############
adler32.obj: ../reader/zlib/*.c ../reader/zlib/*.h
$(CC) $(CFLAGS) /c ../reader/zlib/*.c
###########
### jma ###
###########
jma.obj: ../reader/jma/*.cpp ../reader/jma/*.h
$(CC) $(CFLAGS) /c ../reader/jma/*.cpp
Here you can see the "/link" switch with 2 parameters, you can add your's here.
Concerning my problem, i will continue to use the ImportC wich seems to be a little bit better than the old desc file i used to use
[/quote]
Posted: Tue Aug 01, 2006 9:11 am
by inc.
Ragarding the Manifest Problem this here may be a solution? Well I just encountered it and will try figuring out:
http://www.codeproject.com/cpp/vcredists_x86.asp