Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » U++ Library support » U++ Library : Other (not classified elsewhere) » Building & using U++ without TheIDE
Re: Building & using U++ without TheIDE [message #11637 is a reply to message #11621] Wed, 19 September 2007 23:06 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Quote:


In Debug.cpp, sLogFile, FromSysChrSet causes a segmentation fault on program (correct) shutdown in Code::Blocks/MinGW (with UNICODE, otherwise it isn't called).



I do not get this... Something else must be broken.

Quote:


For things such as clipboard, To/From Ansi/Unicode charset probably should be defined separately. It's possible that Ansi strings need to be posted on clipboard from a unicode app (maybe vice versa too, but rather unlikely).



Win32API explicitly states that ANSI - UNICODE conversions are performed.

Mirek
Re: Building & using U++ without TheIDE [message #11639 is a reply to message #11637] Wed, 19 September 2007 23:56 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
luzr wrote on Wed, 19 September 2007 23:06

Quote:


In Debug.cpp, sLogFile, FromSysChrSet causes a segmentation fault on program (correct) shutdown in Code::Blocks/MinGW (with UNICODE, otherwise it isn't called).



I do not get this... Something else must be broken.

Quote:


For things such as clipboard, To/From Ansi/Unicode charset probably should be defined separately. It's possible that Ansi strings need to be posted on clipboard from a unicode app (maybe vice versa too, but rather unlikely).



Win32API explicitly states that ANSI - UNICODE conversions are performed.

Mirek


OK about clipboard...

In Debug.cpp, did FromSysChrSet do Unicode->Ansi conversion? Try to add this to sLogFile function:

static char out[1024];
FromUnicode(out, s, wstrlen(s), CHARSET_DEFAULT);

With some wchar[] as s.

Though it could be just a GDB problem...
Re: Building & using U++ without TheIDE [message #11641 is a reply to message #11639] Thu, 20 September 2007 05:39 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Sergei, now I am a bit confused. Please, what is crashing, the current U++ code or your Log.cpp patched to use UNICODE?

(BTW, there is IMO no need to use UNICODE there... the names of .log files are simple and fixed, as long as you do not insist about puttin hebrew characters to .exe file names - and even then it would work).

Mirek
Re: Building & using U++ without TheIDE [message #11642 is a reply to message #11641] Thu, 20 September 2007 13:29 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
I didn't want to use Unicode, I really don't care how wrong it writes in debug, that's why I initaially left SysChrSet and didn't replace with SsytemCharset like everywhere else. But:

::GetModuleFileName(NULL, fn, 512);

In UNICODE fn has to be const WCHAR*, and it's char*. So I used the WinCE code:

wchar wfn[256];
::GetModuleFileName(NULL, wfn, 512);
strcpy(fn, FromSysChrSet(wfn));

What crashes is this function in Debug.cpp:

#ifdef PLATFORM_WIN32
static void sLogFile(char *fn, const char *app = ".log")
{
#ifdef PLATFORM_WINCE
wchar wfn[256];
::GetModuleFileName(NULL, wfn, 512);
strcpy(fn, FromSysChrSet(wfn));
#else
::GetModuleFileName(NULL, fn, 512);
#endif
char *e = fn + strlen(fn), *s = e;
while(s > fn && *--s != '\\' && *s != '.')
;
strcpy(*s == '.' ? s : e, app);
}
#endif

It's called after APP_MAIN finishes execution. It crashes if you change to this (don't define UNICODE or anything else, crashes "out of the box"):

#ifdef PLATFORM_WIN32
static void sLogFile(char *fn, const char *app = ".log")
{
#ifdef PLATFORM_WINCE
wchar wfn[256];
::GetModuleFileName(NULL, wfn, 512);
strcpy(fn, FromSysChrSet(wfn));
#else
wchar wfn[256];
::GetModuleFileNameW(NULL, wfn, 512);
FromUnicode(fn, wfn, wstrlen(wfn), CHARSET_DEFAULT);
#endif
char *e = fn + strlen(fn), *s = e;
while(s > fn && *--s != '\\' && *s != '.')
;
strcpy(*s == '.' ? s : e, app);
}
#endif


OK. Not "out of the box". Yesterday it crashed, today GDB just gets stuck and doesn't terminate the program. But the problem is there, since in MSVC it also crashes in debug (unhandled exception in vcont.h). It's the same bug/something, in Code::Blocks it also got segmentation fault somewhere in vectors from FromUnicode call. And both times it happened inside here:

inline
static CharSetData& s_cset(byte charset)
{
return s_map()[ResolveCharset(charset)];
}

Hope that helps.
Re: Building & using U++ without TheIDE [message #11646 is a reply to message #11642] Thu, 20 September 2007 14:51 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Ah, I see, obviously!

Well, what about using A version (GetModuleFileNameA) of function instead of converting?

I guess the reason of crash has a lot to do with what I have stated before: LOG has to work ALWAYS.

I believe that you have altered it in a way that makes it depend on Charset system. And it gets called when the Charset system is destructed (at the end of program).

BTW, if you fix this using "A" versions, please check the log. IMO it is quite likely that there is some diagnostic info there logged during the program exit (what likely happened: Some problem during exit/destriction, being logged -> log crashed).

Mirek

P.S.: Actually, yes, now I remeber that back when I was testing WinCE U++ ("experimental"), it was crashing at the end of program Smile
Re: Building & using U++ without TheIDE [message #11649 is a reply to message #11646] Thu, 20 September 2007 15:11 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
Hehe, known yet forgotten bug Razz

I changed to A version, obviously it works (it's the same it was before - no unicode), and I see no log.

Of course debug could use A versions everywhere, but why not just save the possible log filename in both char[] and wchar[] variants on load? That way no conversion would be necessary. Or does log filename change during execution?

P.S. Stumbled upon "Panic" message. How about something more professional-looking, like "Exception" or "Fatal Error"?
Re: Building & using U++ without TheIDE [message #11659 is a reply to message #11360] Thu, 20 September 2007 21:57 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
Update: I'm nearly done (at least for the first release) making U++ SCU-compatible. Console and GUI work, MSVC seems to work in Debug. .lay, .iml, .t work. zlib was updated to 1.2.3 and modified to work, png was slightly modified (probably should update later, it's 2001 version, there's 2007 version on the website) and works, gif and bmp worked out of the box, jpg was seriously modified (I hate that C-style polymorphism...) but now works. Left is tif. Other stuff is untested, but sqlite3 definitely does not work Crying or Very Sad .
Re: Building & using U++ without TheIDE [message #11675 is a reply to message #11360] Fri, 21 September 2007 03:36 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
I'm testing which packages compile as SCU and which don't. I've encountered some problems:

Inner Geom packages use T??? includes. Commenting them doesn't help, since geomcoord has this:
struct Tree : RefBase
{
Tree(pick_ Node& root) : root(root) {}

Node root;
};
RefBase is only defined in Web. Is that the same RefBase? If yes, GeomCoord should have uses Web. If not, what RefBase does it need, and there is then naming conflict.

Ole Ctrl has member of type Thread. But I'm not compiling multithreaded. Is multithreading a requirement for Ole Ctrl, or should there be some kind of #ifdef?

MySql didn't compile. I don't have #include <Sql.h>, and I don't know where MYSQL is defined (I need to install MySQL?). PostgreSQL wants #include <libpq-fe.h>, I have to install something too, right?

Web/SSL wants #include <openssl/ssl.h> and #include <openssl/err.h>...

Zim, and removed stuff in png, gif and Draw/hrr use AlphaArray, which is never defined -> can't build Zim.


List of compileable packages (in MSVC) ATM (commented ones don't compile):

#include <UppPkg/Core.h>
#include <UppPkg/CppBase.h>
#include <UppPkg/Crypto.h>
#include <UppPkg/CtrlCore.h>
#include <UppPkg/CtrlLib.h>
#include <UppPkg/Draw.h>
#include <UppPkg/Esc.h>
//#include <UppPkg/Geom_Coords.h>
//#include <UppPkg/Geom_Ctrl.h>
//#include <UppPkg/Geom_Draw.h>
#include <UppPkg/Geom.h>
#include <UppPkg/GLCtrl.h>
#include <UppPkg/GridCtrl.h>
//#include <UppPkg/MySql.h>
//#include <UppPkg/Ole_Ctrl.h>
#include <UppPkg/Ole.h>
#include <UppPkg/OleDB.h>
#include <UppPkg/Oracle.h>
#include <UppPkg/PdfDraw.h>
#include <UppPkg/plugin_bmp.h>
//#include <UppPkg/plugin_bz2.h>
#include <UppPkg/plugin_dbf.h>
#include <UppPkg/plugin_ftp.h>
#include <UppPkg/plugin_gif.h>
#include <UppPkg/plugin_jpg.h>
//#include <UppPkg/plugin_ndisasm.h>
//#include <UppPkg/plugin_pcre.h>
#include <UppPkg/plugin_png.h>
//#include <UppPkg/plugin_sqlite3.h>
//#include <UppPkg/plugin_tif.h>
#include <UppPkg/plugin_z.h>
//#include <UppPkg/plugin_zim.h>
//#include <UppPkg/PostgreSQL.h>
#include <UppPkg/Report.h>
#include <UppPkg/RichEdit.h>
#include <UppPkg/RichText.h>
#include <UppPkg/Sql.h>
#include <UppPkg/SqlCtrl.h>
//#include <UppPkg/Web_SSL.h>
#include <UppPkg/Web.h>


I believe ndisasm should be excluded unless building TheIDE, since it's GPL, right?

Re: Building & using U++ without TheIDE [message #11680 is a reply to message #11675] Fri, 21 September 2007 09:49 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Thu, 20 September 2007 21:36

I'm testing which packages compile as SCU and which don't. I've encountered some problems:

Inner Geom packages use T??? includes. Commenting them doesn't help, since geomcoord has this:
struct Tree : RefBase
{
Tree(pick_ Node& root) : root(root) {}

Node root;
};
RefBase is only defined in Web. Is that the same RefBase? If yes, GeomCoord should have uses Web. If not, what RefBase does it need, and there is then naming conflict.



Sorry for the mess. Geom is not "canonical".

Quote:


Ole Ctrl has member of type Thread. But I'm not compiling multithreaded. Is multithreading a requirement for Ole Ctrl, or should there be some kind of #ifdef?



Yes. Which makes us aware abot a new problem Smile (Not only debug/release, but also single/multithreaded).

Quote:


MySql didn't compile. I don't have #include <Sql.h>, and I don't know where MYSQL is defined (I need to install MySQL?). PostgreSQL wants #include <libpq-fe.h>, I have to install something too, right?



Yes and yes. I guess this rules out the possibility to have them in the same library.

Quote:


Web/SSL wants #include <openssl/ssl.h> and #include <openssl/err.h>...



Same issue.

Quote:


Zim, and removed stuff in png, gif and Draw/hrr use AlphaArray, which is never defined -> can't build Zim.



Noncanonical mess Sad On the positive note, your efforts will finally detect all these problems Smile

List of compileable packages (in MSVC) ATM (commented ones don't compile):
[/quote]

OK, these commented out packages are canonical for non-SQL development:

//#include <UppPkg/plugin_bz2.h>
//#include <UppPkg/plugin_pcre.h>
//#include <UppPkg/plugin_tif.h>


Quote:


I believe ndisasm should be excluded unless building TheIDE, since it's GPL, right?



Yes.

Mirek
Re: Building & using U++ without TheIDE [message #11682 is a reply to message #11680] Fri, 21 September 2007 13:41 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
When you say non-canonical, should I understand that as "not-yet-working" and exclude it for now?

Multithreading is a problem, turns out... So there's a need for 2 release libs, at the very least. SQL too, can't it be turned into stand-alone? Just install whatever is needed and add the necessary headers to the packages. Or simply compile a lib on a computer that has everything installed. Having separate libs for SQL would be too many libs...

The three packages you marked seem canonical for me too. It's just that they don't work in SCU out-of-the-box. Naming conflicts etc. (should be resolveable). bz2, libtiff, libpng could/should be updated.

Others that don't work in SCU are ndisasm and sqlite3.


I'll rebuild, check out warnings, and package what I've done. What doesn't work can be fixed later. I don't want to get out of sync with the main sources.
Re: Building & using U++ without TheIDE [message #11693 is a reply to message #11682] Sat, 22 September 2007 00:16 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Fri, 21 September 2007 07:41

When you say non-canonical, should I understand that as "not-yet-working" and exclude it for now?



Well, they are working, but are not core libs and are not polished.

Quote:


I'll rebuild, check out warnings, and package what I've done. What doesn't work can be fixed later. I don't want to get out of sync with the main sources.



OK.
Re: Building & using U++ without TheIDE [message #11694 is a reply to message #11360] Sat, 22 September 2007 00:18 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
OK, I thought everything worked, I was wrong Sad

I've built an example with all the "working" packages under MSVC, debug was built, it worked. Building the same project under MinGW in release worked. But in MinGW/debug it didn't. Instead of working, debugger just hanged without reaching the first line of the program. Executing resulted in a memory could not be written error.

This scenario works in debug:

#include <UppPkg/Core.h>
#include <UppPkg/CppBase.h>
#include <UppPkg/Crypto.h>
#include <UppPkg/CtrlCore.h>
#include <UppPkg/CtrlLib.h>
#include <UppPkg/Draw.h>
#include <UppPkg/Esc.h>
#include <UppPkg/Geom.h>
#include <UppPkg/GLCtrl.h>
#include <UppPkg/GridCtrl.h>
#include <UppPkg/Ole.h>
#include <UppPkg/PdfDraw.h>
#include <UppPkg/plugin_bmp.h>
//#include <UppPkg/plugin_dbf.h>
//#include <UppPkg/plugin_ftp.h>
#include <UppPkg/plugin_gif.h>
//#include <UppPkg/plugin_jpg.h>
#include <UppPkg/plugin_png.h>
#include <UppPkg/plugin_z.h>
#include <UppPkg/Report.h>
#include <UppPkg/RichEdit.h>
#include <UppPkg/RichText.h>
//#include <UppPkg/Web.h>

Uncommenting any package results in the bug I mentioned above. I tried to see what happens there. Uncommented dbf, excluded the class DbfStream itself - works. Seems like having the class in the code results in this weird bug in debug mode. Other packages are bigger and more difficult to debug, but I doubt there's any serious error since it works in release and in MSVC's debug.

Becoming more interesting: removing GridCtrl makes it possible to use dbf, ftp and jpg (but not Web), without the bug. With GridCtrl none of them can be used.


OK, I had an idea and removed #define flagDEBUG and #define flagDEBUG_FULL (while still using MinGW/debug). Guess what, it works. Removing only debug_full wasn't enough, but removing flagDEBUG too solved the problem. So, what exactly does flagDEBUG do that could cause thing go wrong?


P.S. I have a feeling it has something to do with LG/LOG/LLOG/... #defines. GridCtrl redefines LG, but removing it and replacing all LG with LGR in it didn't help...


Edit: I found that I incorrectly used GridCtrl. As Mirek said, although usually the main header is the first file, it's not always the case. Well, that's the example... But unfortunately fixing it and renaming LG to LGD (so that it wouldn't conflict with CtrlCore's log) didn't make any difference. Uncommenting either GridCtrl or Web makes debug break.

[Updated on: Sat, 22 September 2007 01:27]

Report message to a moderator

Re: Building & using U++ without TheIDE [message #11710 is a reply to message #11694] Sun, 23 September 2007 10:54 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Fri, 21 September 2007 18:18


P.S. I have a feeling it has something to do with LG/LOG/LLOG/... #defines. GridCtrl redefines LG, but removing it and replacing all LG with LGR in it didn't help...



Ah, of course. Manual SCU approach.

Do you undefine macros defined in .cpp? Smile

(BLITZ does this automatically).

Mirek
Re: Building & using U++ without TheIDE [message #11714 is a reply to message #11710] Sun, 23 September 2007 16:22 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
luzr wrote on Sun, 23 September 2007 10:54

sergei wrote on Fri, 21 September 2007 18:18


P.S. I have a feeling it has something to do with LG/LOG/LLOG/... #defines. GridCtrl redefines LG, but removing it and replacing all LG with LGR in it didn't help...



Ah, of course. Manual SCU approach.

Do you undefine macros defined in .cpp? Smile

(BLITZ does this automatically).

Mirek



No. That's why I'm trying to ensure there are no naming conflicts. Macros are evil Twisted Evil

But since that works in MSVC I doubt that would be a naming clash bug or something similar. Maybe I should try MinGW 4.2 instead of 3.4.5.
Re: Building & using U++ without TheIDE [message #11723 is a reply to message #11360] Sun, 23 September 2007 20:51 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
OK, I've finalized everything I did. Not perfect, but works. Everything is in the zip, there's readme.txt and changelog.txt. Any comments/suggestions/questions are welcome. Would be interesting to see times/sizes on other computers.
  • Attachment: U++.zip
    (Size: 1.09MB, Downloaded 313 times)
Re: Building & using U++ without TheIDE [message #11759 is a reply to message #11723] Tue, 25 September 2007 11:44 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
I think it would be better to solve INITBLOCK SCU issue by using

BLITZ_INDEX__

macro.
Re: Building & using U++ without TheIDE [message #11774 is a reply to message #11759] Tue, 25 September 2007 16:18 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
luzr wrote on Tue, 25 September 2007 11:44

I think it would be better to solve INITBLOCK SCU issue by using

BLITZ_INDEX__

macro.


But where/how is BLITZ_INDEX__ defined? Especially if BLITZ isn't present.

Did you try to use lib or SCU? Did any change make it into the main source?

P.S. since U++ and many plugins are BSD-style licensed and programs are statically linked, what exactly should be present in the documentation of a program using U++? One copyright notice per package/plugin? Is there a compilation of licenses to be included?
Re: Building & using U++ without TheIDE [message #11788 is a reply to message #11774] Tue, 25 September 2007 23:07 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Tue, 25 September 2007 10:18

luzr wrote on Tue, 25 September 2007 11:44

I think it would be better to solve INITBLOCK SCU issue by using

BLITZ_INDEX__

macro.


But where/how is BLITZ_INDEX__ defined? Especially if BLITZ isn't present.

Did you try to use lib or SCU? Did any change make it into the main source?



You have to define it in SCU.

The imporant thing is that INITBLOCK will use this macro to make its internally generated static function name unique.

Quote:


P.S. since U++ and many plugins are BSD-style licensed and programs are statically linked, what exactly should be present in the documentation of a program using U++? One copyright notice per package/plugin? Is there a compilation of licenses to be included?



Actuallly, I have this in ToDo - it should be easily possible to generate license info by TheIDE for the current project Smile

Mirek
Re: Building & using U++ without TheIDE [message #11795 is a reply to message #11360] Wed, 26 September 2007 00:52 Go to previous messageGo to next message
sergei is currently offline  sergei
Messages: 94
Registered: September 2007
Member
But how am I supposed to define that? In general case it would have to be redefined before every file, since __LINE__ isn't unique, and stuff like counter in MSVC aren't portable. The headers would be full of #undef and #define. Once replacing all these INIT/EXITBLOCK and manually adding them unique identifiers like I did should solve the issue (2 seconds more typing in case you'll add another INITBLOCK to give it a name - filename usually is unique enough).
Re: Building & using U++ without TheIDE [message #11805 is a reply to message #11795] Wed, 26 September 2007 13:41 Go to previous messageGo to previous message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
sergei wrote on Tue, 25 September 2007 18:52

But how am I supposed to define that? In general case it would have to be redefined before every file, since __LINE__ isn't unique, and stuff like counter in MSVC aren't portable. The headers would be full of #undef and #define.



Yes. But you do not need to fix existing code.

Quote:


Once replacing all these INIT/EXITBLOCK and manually adding them unique identifiers like I did should solve the issue (2 seconds more typing in case you'll add another INITBLOCK to give it a name - filename usually is unique enough).



Ah, so you do think I should remove nameless INITBLOCK? Sad

I am not very happy about such idea... I hate inventing unique ids with the only purpose - being unique.

Mirek
Previous Topic: *.tpp files in SVN
Next Topic: console + WIN-GDI
Goto Forum:
  


Current Time: Thu Mar 28 10:17:26 CET 2024

Total time taken to generate the page: 0.01355 seconds