PB 3.91 User Libs, PellesC, Polink - Unresolved Symbols

[upnorth]

I have been writing several user libraries in C using PellesC 2.80. Mostly just for learning. Some libraries work fine. In others they will compile fine in PellesC, but will fail when compiling the final program in PB with Unresolved Symbols reported by Polink. Such as ___log ___stderr ___ctypelib and many others.

These should be readily available for linking as Fred has placed the appropriate libs in the Purelibraries\Windows\Libraries folder for use during the link.

I know that Fred changed the linker in 3.91 to Pelles linker, and it seems much less forgiving then the old lcc linker.

I have tried setting the LIB and INCLUDE environment variables and various compilier directives etc, but I still get the unresolved symbol errors.

Question: Is there something that I'm missing ? Perhaps some compilier option or other configuration ? I've selected __stdcall and the Microsoft Extensions as suggested in other posts, but no luck.

Did anyone else have this problem and if so how did you fix it ?

Any other info about how you've changed your lib development methods now that the Pelles linker is used would be helpful. Thanks.

[upnorth]

Ouch! Nobody wants to talk about this topic heh ?

Well anyway, here's a neat trick. In your C source code for a User Library, you can put this line:

Code: Select all

#pragma comment( linker , "/VERBOSE" )

This causes verbose output from the linker when PB is compiling the final program that uses this user lib. When compiling with PellesC it does anyway. I Don't know about other compilers.

Unfortunately , the output is truncated at about 1,100 characters or so, in the resulting dialog box. The output is also stored in the file linker.out in the purebasic\compilers directory, but it is truncated also. This also causes polink.exe to apparently hang, as it must be terminated from the process list.

I think this is a bug. I should be able to see all the verbose output from the linking and compiling process to trouble shoot when building user libraries.

Fred ? Can I get an option to view the verbose output from polink ? Pretty please ?

[KarLKoX]

When PB complains about a missing resovled symbol, it is due to your .desc file : you must add the lib dependy for your user lib.
If you are using the __sterrr func, search the PellesC's directory for this symbol, you might find where this func is compiled and add this lib to your desc file.
If this lib doesn't exist in the purebasic librairie, you can add it in your PellesC's project though you will not have to add it in your .desc file.

[jack]

i too have problems with PellesC and lcc, tried just about every setting,
msvc 6 works once you know how to circumvent the "unresolved external symbol _fltused"
btw i could not get msvc 7 to work, sorry that i spent good money on it.
you get a "unresolved external symbol _ftol2" that microsoft never bothered to fix.
i am hoping that Pelle will fix his compiler soon.

[edit]
i had searched the web when i first encountered the _ftol2 problem and found no good answer,
had better luck today. http://www.flipcode.com/cgi-bin/msg.cgi ... eral&id=-1
anyway, after inserting this snippet everything seems to work.

Code: Select all

void _ftol2()
{
	int r;
	_asm
	{
		fistp r
		mov eax, r
	}
}

i will be able to use vc7 after all

[KarLKoX]

I got this error too (ftol2) and linking with the msvrt version of vc7 resolved this pb : in fact, the purebasic folder have the vc6 one.
For fltused, a simple :

Code: Select all

#ifdef	__cplusplus
	extern "C" {
	#endif 
		char _fltused;
	#ifdef __cplusplus
	}
	#endif

resolved this problem

[jack]

thanks KarLKoX

[upnorth]

@KarLKoX

.Desc files do not have any syntax to add .lib's as far as I know. You can specify any .DLL's that your dependent on, but I am not using any .DLL's. PellesC has all standard C libraries in a single file crtmt.lib. ("C" Runtime Library Multi-Threaded) Fred has his version of this lib in \purebasic\purelibraries\windows\libraries as crtmt.lib and crtmt2.lib. These contain the functions that are not resolving, as well as all other standard C functions. (Look inside them with a hex editor and see what I mean) Since purebasic is now using PellesC compilier, libraries, resources etc, I should not have to do anything special for them to be available during the PB compile.

The only thing I could do is use polib.exe to add more C libraries to my user library. This should not be necessary as Fred has them all available for the link in the purebasic folders as I stated above. Besides, this just makes the user library bigger and bigger.

I may be able to find out the problem if I could see the complete log of the link, but as I stated above, PB chokes on large link logs.

@jack

Since PB is now based on PellesC, I figured that would be the most compatible (and cheapest) way to go. ftol is "float to long". This function should be available for linking without doing anything special. So should log, stderr, ctypelib etc. Maybe it's just a naming problem. Such as log() _log() __log() ___log() etc. Perhaps the linker just can't find the function because it's name is "decorated". But the PellesC headers define the standard name too. That is what is so confusing.

By the way I'm not calling any of these functions directly, perhaps some function I am using is calling them in the background.

I just feel like something is wrong if I have to do anything extraordinary just to compile and link a library.