Userlibs via diff. dev environments (DevC++,VC6,VS2005,etc.)

[inc.]

Hi,
till now I had no problems building my userlibs under DevC++ or MSVC++6.

But I have 3 questions:

1.
I took a look at VisualStudio 2005.
The dev environment is very nice and it makes fun building Userlibs in C/C++.
BUT! After compiling a ststic lib project in VS2005 and doing the LibraryMaker workout, in PB Polink reports errors (Im not at home right now so I do assume these where unresolved ext. symbols).
If compiling that similair C code using DevC++ or MSVC++6 as static lib then .... no compiling-problems when using the resulted userlib in PB.

Is that a .Net based issue? Do I have to setup something special in VS2005 or adding something specific in the Desc File?

Someone already does build Userlibs using VS2005?


2.
I figured out that resulting Dlls out of VS2005 are significant smaller in their size compared to Dlls compiled with MSVC++6. Also here, is it a must that the User of that Dll has to install that Net stuff on his system?
(Btw. seems that __stdcall in front of funct. declarations in the code are ignored in VS2005, I always have to setup the calling convention in the genral "project options/C++/advanced/" to __stdcall to make the dll functions stdcall compilant.


3.
I recognised that I cant just link obj's using Polink for PB userlibrary purposes IF some obj's do differ from their root language (C or ASM).
Thats why in the .desc file I have to set if the obj/libs are C or ASM based.

I figured out that at MSVC++ and VS2005 I also can let output an ASM listing of my C/C++ code when compiling.
Could this be an approach if I want to use polink on a list of Tailbite(ASM) resulted obj's and obj's out of the VC++6 resulted ASM code?

Whats the difference between the obj's out of C/C++ and ASM as I have to set that up in my desc files?


As always ... thanks a lot for replies!

[KarLKoX]

1 - C++ code must be compiled with multithreaded option,
2 - No, only .net code require the .net framework, C/C++ code only need the msvcrt8 dll runtime,
3 - i never linked obj files for PB so i can't help you here

[inc.]

Thanks for your reply

1 - C++ code must be compiled with multithreaded option

That has been set (imho... VStudio2005 doesn't even support singlethreaded anymore)

[KarLKoX]

Ah yes, you are right, vs2005 only support multithreaded compilation.
What sort of error do you have ?

[inc.]

Ill have a look and I let you know (probably this weekend).

[inc.]

Hi KarLKoX,

sorry the late reply.


I figured out that the unresolved symbols problem mentiond above does occure when two things get in combination:

1. If u use for compiling VisualStudio 2005 and ....
2. If you do link with the PBs provided msvcrt.lib!

Yesterday I did some tests using the new feature "Import" of PB.
I compiled a static Lib in VS 2005 Std. (like if I would do for Userlib purposes). In the PB code I also did let first import the msvcrt.lib and then my own lib/obj.

Code: Select all

; // Link with msvcrt library
Import "msvcrt.lib"
EndImport

; // Link with my Lib
Import "C:\My\Path\To\AVSredirect.lib"
    Function1()
    Function2()
EndImport

In my case this does result in unresolved symbols.

But when using the msvcrt.lib provided with VS 2005 then it works.

Code: Select all

; // Link with msvcrt library
Import "C:\MyPathTo\VC\lib\msvcrt.lib\msvcrt.lib"
EndImport

; // Link with my Lib
Import "C:\MyPathTo\AVSredirect.lib"
    Function1()
    Function2()
EndImport

[Nik]

Seems like MSV2005 has a different dll

[inc.]

Yup, at least it comes with some symbols added.

But that could be a bit complicated if someone wants to provide/share a lib for/to the PB community. To me this Import/EndImport support in PB is a very good advantage.

It gots a significant advantage over a regular userlib.

1. No special conversion to PB_* prefixes needed in the c/c++ root code.
2. No need to generate a .desc file ...
3. .. but simply provide with your lib a little include (.pbi) file where the imported fuctions are named. In case of function name conflicts the user simply could "wrap" the lib's symbol names to diff functionnames using "as". I remember that there was a possibility of nameconflicts in some cases if you got a big collection of userlibs loaded in PB.

But imho its a bit more incomfortable if someone everytime also has to provide the VS 2005 msvcrt.lib when sharing his lib out of VS 2005 with someone else.

Is Fred aware of that msvcrt subject? Could it be that this VS2005 msvcrt on the other hand could be result in problems when linking with some other libs resulted out of i.E. gcc, lcc, pelles etc. compilings?

[traumatic]

But imho its a bit more incomfortable if someone everytime also has to provide the VS 2005 msvcrt.lib when sharing his lib out of VS 2005 with someone else.

There's no need to, just link the needed libs (msvcrt.lib) to your lib
(AVSredirect.lib), no need for a second Import/EndImport.

IMHO dependencies on external libs is something the programmer
of the library has to take care of, not the end-user.

[inc.]

Hi Traumatic,

I managed it that my obj gets linked with msvcrt.lib when resulting as lib out of VS2005 C++. So Im able to use the resulted lib as standalone when "import"'ing in my PB code. Thanks for the hint (which you already gave me some time before).

Now I recognised that the whole msvcrt.lib is "included" in my resulted lib. So is there a way that only the needed symbols out of msvcrt.lib are included in my final lib?
The obj itself takes about 40k but when including the msvcrt.lib into my Project the resulted lib is about 950k - so the whole amount of symbolf of the msvcrt.lib has been included. Maybe there is another way of forced-linking with an external lib so only the needed symbols get included.

Thanks for your support.

Inc.

[traumatic]

Hi Inc.!

If you're concerned about library-size (executable won't change anyway),
don't link the entire .lib, only the needed .obj (from the .lib).

[inc.]

Means I wold have to "explode" the msvcrt.lib using polib?

But ...

a) I would have to find out in which of the listed internal obj's the needed symbols are included.
b) If I use ...
polib.exe /EXPLODE "D:\myPathTo\msvcrt.lib

... an error "POLIB: fatal error: Die Datei ist vorhanden." appears (in english: FIle already exists). If I do add /OUT:FileName the same error appears.

[jack]

probably because msvcrt.lib is an import lib of msvcrt.dll

[inc.]

Yes, ... youre right, it seems so:
MSVCR80.dll is the one most accessed via that msvcrt.lib.[/code]

[traumatic]

a) I would have to find out in which of the listed internal obj's the needed symbols are included.

That's one solution, yes, but I've got most (if not all) objects already
seperated on some MSDN CD, lots of them coming with sourcecode
(all the Intel stuff).

b) If I use ...
polib.exe /EXPLODE "D:\myPathTo\msvcrt.lib

Works here (?)