c++.announce - Linking with MFC 4.2 and C++ 8.28 beta
- Walter (12/12) Apr 02 2002 Some of you have noticed problems with unresolved symbols when linking w...
- Jan Knepper (5/17) Apr 02 2002 Are these people using a recompiled MFC?
-
Chris Widdows
(16/39)
Apr 02 2002
On Tue, 02 Apr 2002 08:10:25 -0500, Jan Knepper
- Jan Knepper (11/23) Apr 02 2002 With the original binairies, compiled with a compiler without wchar_t as...
- Chris Widdows (20/43) Apr 02 2002 As I understand and experience it, with a compiler WITH a real wchar_t
- Jan Knepper (19/39) Apr 02 2002 Yup!
- Chris (29/55) Apr 02 2002 Well the structure of the newer MFC resides one level of the two that ar...
- Jan Knepper (18/47) Apr 02 2002 Well, in that case you could install the newer MFC (.tar.gz) in an diffe...
Some of you have noticed problems with unresolved symbols when linking with
MFC 4.2. I have tracked down what appears to be the problem, and posted an
update:
ftp://ftp.digitalmars.com/Digital_Mars_C++/Patch/beta.zip
The problem comes from having switched to wchar_t being a real type rather
than an alias for unsigned short. The solution is to add:
#pragma DMC mfc
to afx.h which will tell the compiler to maintain binary compatibility with
the MFC dll's. Included in the patch are new compilers and a new afx.h.
The patch also includes the new empty base class optimization, which can
give your STL applications a nice speed boost.
-Walter
Apr 02 2002
Are these people using a recompiled MFC?
I have recompiled MFC since and never experienced that problem!
(Or are they using a .DLL instead of a static library?!)
Jan
Walter wrote:
Some of you have noticed problems with unresolved symbols when linking with
MFC 4.2. I have tracked down what appears to be the problem, and posted an
update:
ftp://ftp.digitalmars.com/Digital_Mars_C++/Patch/beta.zip
The problem comes from having switched to wchar_t being a real type rather
than an alias for unsigned short. The solution is to add:
#pragma DMC mfc
to afx.h which will tell the compiler to maintain binary compatibility with
the MFC dll's. Included in the patch are new compilers and a new afx.h.
The patch also includes the new empty base class optimization, which can
give your STL applications a nice speed boost.
-Walter
Apr 02 2002
On Tue, 02 Apr 2002 08:10:25 -0500, Jan Knepper <jan smartsoft.cc> wrote: Jan, I'm having this with the original binaries, the recompiled ones should be ok. As I understand it, the original binaries were built when wchar_t was unsigned short, which results is the current compiler emitting names mangled with wchar_t and having to link with exports mangled with unsigned short. The newer compiler has a wchar_t so if you used that to compile MFC, it should link without the pragma. I tried rebuilding MFC with the original source (CD and subsequent patches), didn't work (but perhaps I chose the wrong method). I downloaded the latest release, that didn't work either, got an internal compiler error, so I notified Walter (again, sigh). I've just tested the patch, and it works for me, so Walter thank you for the quick response. ChrisAre these people using a recompiled MFC? I have recompiled MFC since and never experienced that problem! (Or are they using a .DLL instead of a static library?!) Jan Walter wrote:Some of you have noticed problems with unresolved symbols when linking with MFC 4.2. I have tracked down what appears to be the problem, and posted an update: ftp://ftp.digitalmars.com/Digital_Mars_C++/Patch/beta.zip The problem comes from having switched to wchar_t being a real type rather than an alias for unsigned short. The solution is to add: #pragma DMC mfc to afx.h which will tell the compiler to maintain binary compatibility with the MFC dll's. Included in the patch are new compilers and a new afx.h. The patch also includes the new empty base class optimization, which can give your STL applications a nice speed boost. -Walter
Apr 02 2002
Chris Widdows wrote:I'm having this with the original binaries, the recompiled ones should be ok. As I understand it, the original binaries were built when wchar_t was unsigned short, which results is the current compiler emitting names mangled with wchar_t and having to link with exports mangled with unsigned short. The newer compiler has a wchar_t so if you used that to compile MFC, it should link without the pragma.With the original binairies, compiled with a compiler without wchar_t as a type you will be in trouble.I tried rebuilding MFC with the original source (CD and subsequent patches), didn't work (but perhaps I chose the wrong method). I downloaded the latest release, that didn't work either, got an internal compiler error, so I notified Walter (again, sigh).I must have been lazy (or to buzy). I still use 8.1d.1n for production because I noticed there were isssue's with later versions of the compiler. I was not been able to recompile any of my projects with a certain successor and have not tried the newer versions. What are the problems you are having with recompiling MFC though?! Are you using the .tar.gz from the website?I've just tested the patch, and it works for me, so Walter thank you for the quick response.That will work. Jan
Apr 02 2002
On Tue, 02 Apr 2002 09:36:51 -0500, Jan Knepper <jan smartsoft.cc> wrote:Chris Widdows wrote:As I understand and experience it, with a compiler WITH a real wchar_t AND linking with the ORIGINAL MFC libs/dll's AND using UNICODE you will be in trouble. (caps are for me, BTW). The compiler that uses an alias for wchar_t WILL link with the original MFC libs/dll's. All compilers should link to libs/dll's they created.I'm having this with the original binaries, the recompiled ones should be ok. As I understand it, the original binaries were built when wchar_t was unsigned short, which results is the current compiler emitting names mangled with wchar_t and having to link with exports mangled with unsigned short. The newer compiler has a wchar_t so if you used that to compile MFC, it should link without the pragma.With the original binairies, compiled with a compiler without wchar_t as a type you will be in trouble.I took the tar from the website, and the one that worked best for me was using the allmfc.mak from the projects subdir. The prj's in the sc subdir didn't work as is. What I really wanted was to rebuild the original source to new MFC's to circumvent the UNICODE build problems I was having. The one on the website is a newer MFC, but installing it breaks 16-bit MFC installed, I tried that as well, but ran into a internal compiler error. Walter's looking into that, as the steps to reproduce are easy (but I don't have then with me right now). As for the original mfc source, the prj's looked a little suspect (release libs coming up in a debug build) and it looked to me that some work was required to get them to build with the newer compiler, so I didn't follow through.I tried rebuilding MFC with the original source (CD and subsequent patches), didn't work (but perhaps I chose the wrong method). I downloaded the latest release, that didn't work either, got an internal compiler error, so I notified Walter (again, sigh).I must have been lazy (or to buzy). I still use 8.1d.1n for production because I noticed there were isssue's with later versions of the compiler. I was not been able to recompile any of my projects with a certain successor and have not tried the newer versions. What are the problems you are having with recompiling MFC though?! Are you using the .tar.gz from the website?I've just tested the patch, and it works for me, so Walter thank you for the quick response.That will work. Jan
Apr 02 2002
As I understand and experience it, with a compiler WITH a real wchar_t AND linking with the ORIGINAL MFC libs/dll's AND using UNICODE you will be in trouble. (caps are for me, BTW).Yes! wchar_t != unsigned short && wchar_t != signed shortThe compiler that uses an alias for wchar_t WILL link with the original MFC libs/dll's.Yup!All compilers should link to libs/dll's they created.<g> They will if you use the proper prototypes for the functions... SetWindowText ( unsigned short * ) is not the same as SetWindowText ( wchar_t * ) anymore...I took the tar from the website, and the one that worked best for me was using the allmfc.mak from the projects subdir. The prj's in the sc subdir didn't work as is.That's probably because I still need to upgrade them to the DMC++ file formats...What I really wanted was to rebuild the original source to new MFC's to circumvent the UNICODE build problems I was having. The one on the website is a newer MFC, but installing it breaks 16-bit MFC installed,Why is that? Do you still need the 16-bit MFC version???I tried that as well, but ran into a internal compiler error. Walter's looking into that, as the steps to reproduce are easy (but I don't have then with me right now).I noticed problems too with one of the later compilers when compiling MFC and MFC applications. I have not gotten the time however to properly report the problems...As for the original mfc source, the prj's looked a little suspect (release libs coming up in a debug build) and it looked to me that some work was required to get them to build with the newer compiler, so I didn't follow through.Correct! I hope to get to that someday soon. For now I first patched IMPLIB.exe so it can parse header files, find a function prototype and add the n for most of the exported functions. It does not work 100%, but so far I have got very good results on the LEADTOOLS .dll's. Jan
Apr 02 2002
On Tue, 02 Apr 2002 13:19:16 -0500, Jan Knepper <jan smartsoft.cc> wrote:Well the structure of the newer MFC resides one level of the two that are included standard. In \dm\mfc\include you have stubs for all mfc headers, going to subdir 32-bit or 16-bit depending on the build. The newer 32-bit should overwrite the previous 32-bit, but leave the 16-bit unaffected IMO. No, I don't really need 16-bit, but it is a feature and I have some tick about removing stuff I might need. There is no real reason other than that would render some options in some dialogs unusable, and I like options to work ;-) But somebody else might really need the 16-bit stuff, and might not like the idea of breaking that to be able to use the latest 32-bit.I took the tar from the website, and the one that worked best for me was using the allmfc.mak from the projects subdir. The prj's in the sc subdir didn't work as is.That's probably because I still need to upgrade them to the DMC++ file formats...What I really wanted was to rebuild the original source to new MFC's to circumvent the UNICODE build problems I was having. The one on the website is a newer MFC, but installing it breaks 16-bit MFC installed,Why is that? Do you still need the 16-bit MFC version???Well the Unicode problem seems solved, and the internal errors seem gone, but the mak's are messed. They're referencing other mak's that are not there (under that name). For instance allmfc.mak reference smfc42d.mak, and I only see sfc42d.mak. I know this easy to solve, but having to do that does not instill great confidence that the results is as intended.I tried that as well, but ran into a internal compiler error. Walter's looking into that, as the steps to reproduce are easy (but I don't have then with me right now).I noticed problems too with one of the later compilers when compiling MFC and MFC applications. I have not gotten the time however to properly report the problems...That would be great, just one prj, load, no adjust, hit rebuild all and every single MFC lib/dll combo is rebuilt. Without even upgrading the MFC stuff, I would still let the libs profit from the advancement in the compiler. Up to now I haven't had any need for MS's latest, the that is included by default works for me.As for the original mfc source, the prj's looked a little suspect (release libs coming up in a debug build) and it looked to me that some work was required to get them to build with the newer compiler, so I didn't follow through.Correct! I hope to get to that someday soon.For now I first patched IMPLIB.exe so it can parse header files, find a function prototype and add the n for most of the exported functions. It does not work 100%, but so far I have got very good results on the LEADTOOLS .dll's.I have a tool that will list any DLL's exported function, ordinal and all and save the output to clipboard. I use it to build a def file for implib that allows the __fhfhf xx to map to the exported _dfhfg or ordinal. That way I let DMC++ generate the symbol it wants, and map it to the correct exported function. As ever there's a system to this and I have never got around scripting it, I just use manual control. I could try your implib to see how it reacts to the dll's I use.JanChris
Apr 02 2002
Jan Knepper <jan smartsoft.cc> Well the structure of the newer MFC resides one level of the two that are included standard. In \dm\mfc\include you have stubs for all mfc headers, going to subdir 32-bit or 16-bit depending on the build. The newer 32-bit should overwrite the previous 32-bit, but leave the 16-bit unaffected IMO. No, I don't really need 16-bit, but it is a feature and I have some tick about removing stuff I might need. There is no real reason other than that would render some options in some dialogs unusable, and I like options to work ;-) But somebody else might really need the 16-bit stuff, and might not like the idea of breaking that to be able to use the latest 32-bit.Well, in that case you could install the newer MFC (.tar.gz) in an different directory and just change the include and lib path's in the IDDE project. That's basically all there is to it. <g>Well the Unicode problem seems solved, and the internal errors seem gone, but the mak's are messed. They're referencing other mak's that are not there (under that name). For instance allmfc.mak reference smfc42d.mak, and I only see sfc42d.mak. I know this easy to solve, but having to do that does not instill great confidence that the results is as intended.Is this in the Projects directory?That would be great, just one prj, load, no adjust, hit rebuild all and every single MFC lib/dll combo is rebuilt. Without even upgrading the MFC stuff, I would still let the libs profit from the advancement in the compiler. Up to now I haven't had any need for MS's latest, the that is included by default works for me.Well, that will be one main .prj file which probably will include quite a few others... MS's latest MFC (I think that is 7.0 by now) I will try to port sometime later this year.Well, the problem with that is that functions seem to reside in a .DLL as L_CreateBitmap. While DMC through compiling generates _L_CreateBitmap 12 The point is, I used to do it the way you do it. Just create a .def file someway somehow. However... that still is a tedeous job, especially if you are talking .DLL't with literally hundreds of exported functions. Yet, I finally got in trouble and patched IMPLIB... It does not always work perfectly (it is not a C/C++ parser so it could take the wrong prototype out of the headers file, like one that is 'commented' I had to add a little check for that yesterday), but it certainly has made my life easier, and adding the little check was a lot easier than writing the .def file manually... JanFor now I first patched IMPLIB.exe so it can parse header files, find a function prototype and add the n for most of the exported functions. It does not work 100%, but so far I have got very good results on the LEADTOOLS .dll's.I have a tool that will list any DLL's exported function, ordinal and all and save the output to clipboard. I use it to build a def file for implib that allows the __fhfhf xx to map to the exported _dfhfg or ordinal. That way I let DMC++ generate the symbol it wants, and map it to the correct exported function. As ever there's a system to this and I have never got around scripting it, I just use manual control. I could try your implib to see how it reacts to the dll's I use.
Apr 02 2002