Menu
▾
▴
wxlua-users
|
From: klaas.holwerda <kho...@xs...> - 2006-03-04 16:51:19
|
Hi, I thought i do a last test with VC6 ( only debug and release multilib ). I see with wxStEdit from wxCode CVS, still this problem, i think this is the same as we had some time ago. If it is already introduced here, later on in wxLua the problem will stay, and eventually in wxArt2D it became a real problem. Francesco how did you solve it that time? Better do it here too. Regards, Klaas --------------------Configuration: wxstedit - Win32 Debug-------------------- Linking... LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of other libs; use /NODEFAULTLIB:library next i get this in all wxLua/apps -------------------Configuration: app_wxlua - Win32 Release Multilib-------------------- Compiling resources... Compiling... lconsole.cpp wxlua.cpp Generating Code... Linking... LINK : warning LNK4089: all references to "OLEAUT32.dll" discarded by /OPT:REF and of course in: --------------------Configuration: app_wxluaedit - Win32 Debug Multilib-------------------- Compiling resources... Compiling... wxledit.cpp wxluaedit.cpp Generating Code... Linking... LINK : warning LNK4098: defaultlib "MSVCRT" conflicts with use of other libs; use /NODEFAULTLIB:library |
|
From: klaas.holwerda <kho...@xs...> - 2006-03-04 17:01:17
|
Hi, And indeed app_wxluaedit app crashes in the class RTTI initalization stuff again. This is for sure because of the warning below. It must be somewhere solved in bakefile. Klaas klaas.holwerda wrote: > > --------------------Configuration: wxstedit - Win32 > Debug-------------------- > Linking... > LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of > other libs; use /NODEFAULTLIB:library > |
|
From: John L. <jla...@gm...> - 2006-03-04 18:55:19
|
On 3/4/06, klaas.holwerda <kho...@xs...> wrote:
> And indeed app_wxluaedit app crashes in the class RTTI initalization
> stuff again.
> This is for sure because of the warning below. It must be somewhere
> solved in bakefile.
> >
> > --------------------Configuration: wxstedit - Win32
> > Debug--------------------
> > Linking...
> > LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of
> > other libs; use /NODEFAULTLIB:library
I think this is because you have compiled wxStEdit in RELEASE?
Unfortunately the wxStEdit build files only output to a single dir so
you have to completely! clean it out and rebuild it.
I'm just using the wxCode bakefiles and I don't think there's a way to
separate the output of the build files? Francesco, is that right? I've
used the bakefiles for your projects as a starting point, but maybe
I've missed something.
Regards,
John Labenski
|
|
From: klaas.holwerda <kho...@xs...> - 2006-03-04 19:48:27
|
John Labenski wrote: > On 3/4/06, klaas.holwerda <kho...@xs...> wrote: > >> And indeed app_wxluaedit app crashes in the class RTTI initalization >> stuff again. >> This is for sure because of the warning below. It must be somewhere >> solved in bakefile. >> >>> --------------------Configuration: wxstedit - Win32 >>> Debug-------------------- >>> Linking... >>> LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of >>> other libs; use /NODEFAULTLIB:library >>> > > I think this is because you have compiled wxStEdit in RELEASE? > Unfortunately the wxStEdit build files only output to a single dir so > you have to completely! clean it out and rebuild it. > No this should not be the case, i have a steditd.lib and a stedit.lib. And i used batch build. BUT it looks there is something not right. Since if i just force the active configuration to build in debug, and rebuild all, i can also run app_wxluaedit (after a rebuild) without problem. At least what i saw in wxLua is that stedit.lib is linked always, i changed it by hand to use wxsteditd.lib. But looking at the size of wxsteditd.lib and wxstedit.lib they are eqaul ( binary too ). I am confused. Klaas |
|
From: John L. <jla...@gm...> - 2006-03-04 20:32:44
|
On 3/4/06, klaas.holwerda <kho...@xs...> wrote: > John Labenski wrote: > > On 3/4/06, klaas.holwerda <kho...@xs...> wrote: > > > >> And indeed app_wxluaedit app crashes in the class RTTI initalization > >> stuff again. > >> This is for sure because of the warning below. It must be somewhere > >> solved in bakefile. > >> > >>> --------------------Configuration: wxstedit - Win32 > >>> Debug-------------------- > >>> Linking... > >>> LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of > >>> other libs; use /NODEFAULTLIB:library > >>> > > > > I think this is because you have compiled wxStEdit in RELEASE? > > Unfortunately the wxStEdit build files only output to a single dir so > > you have to completely! clean it out and rebuild it. > > > No this should not be the case, i have a steditd.lib and a stedit.lib. > And i used batch build. > BUT it looks there is something not right. Since if i just force the > active configuration to build in debug, and rebuild all, > i can also run app_wxluaedit (after a rebuild) without problem. > At least what i saw in wxLua is that stedit.lib is linked always, i > changed it by hand to use wxsteditd.lib. > But looking at the size of wxsteditd.lib and wxstedit.lib they are eqaul > ( binary too ). > I am confused. Since the object files are not put into separate dirs and you probably compiled the RELEASE version first it probably just linked them together for the DEBUG version, hence the libs are the same size. You have to clean it first and do a rebuild to change versions. -John Labenski |
|
From: Francesco M. <f18...@ya...> - 2006-03-05 23:13:52
|
[sending 2nd time - Gmane did not get the first message] klaas.holwerda ha scritto: > John Labenski wrote: >> On 3/4/06, klaas.holwerda >> <kho...@xs...> wrote: >> >>> And indeed app_wxluaedit app crashes in the class RTTI initalization >>> stuff again. >>> This is for sure because of the warning below. It must be somewhere >>> solved in bakefile. >>> >>>> --------------------Configuration: wxstedit - Win32 >>>> Debug-------------------- >>>> Linking... >>>> LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of >>>> other libs; use /NODEFAULTLIB:library >>>> >> >> I think this is because you have compiled wxStEdit in RELEASE? >> Unfortunately the wxStEdit build files only output to a single dir so >> you have to completely! clean it out and rebuild it. >> > No this should not be the case, i have a steditd.lib and a stedit.lib. > And i used batch build. > BUT it looks there is something not right. Since if i just force the > active configuration to build in debug, and rebuild all, > i can also run app_wxluaedit (after a rebuild) without problem. > At least what i saw in wxLua is that stedit.lib is linked always, i > changed it by hand to use wxsteditd.lib. > But looking at the size of wxsteditd.lib and wxstedit.lib they are eqaul > ( binary too ). > I am confused. I'm not sure how batch builds work but as John said, wxStEdit object files always go in the same folder so, unless MSVC does a 'clean project' command between two builds automatically, the batch builds are going to overlap... I'll check it in MSVC asap! Francesco |
|
From: k. h. <kla...@nl...> - 2006-03-06 10:42:57
|
Francesco Montorsi wrote: > > > I'll check it in MSVC asap! > Francesco I will check too, but this weekend CVS was down, which i realized after i thrown away my current wxLua checkout :-(. Anyway, i think batch build is the only feasible way to work with the bakefile generated project files on VC. If not one has to set the active configuration by hand . Ths evening i will check this evening is this is also the case for dependency projects. It would indeed be nice if wxCode used the same system as wxLua. Do you have any idea how we can speed up the patches for bakefile? Is there only a time problem, or are there other issues? Klaas -- Unclassified |
|
From: Francesco M. <f18...@ya...> - 2006-03-06 11:30:37
|
k. holwerda ha scritto: > > > Francesco Montorsi wrote: > >> >> >> I'll check it in MSVC asap! >> Francesco > > I will check too, but this weekend CVS was down, which i realized after > i thrown away my current wxLua checkout :-(. yes, I've got a ton of internet problems too this weekend: gmane did not work for a long time and probably also my ISP had some problem... this basically stopped me so I think it's better to fix another day for a release... see my other mail > Anyway, i think batch build is the only feasible way to work with the > bakefile generated project files on VC. I've never completely understood this: why do you need to build more than one configuration with MSVC projects ? For testing or for development or both ? To test if a project compiles and works in all configs I think it's best to use command line makefiles where you can script all builds; for development I usually use IDE too but I always select 1 config and I've never used batch builds. > If not one has to set the active configuration by hand . Ths evening i > will check this evening is this is also the case for dependency projects. > It would indeed be nice if wxCode used the same system as wxLua. yes, you're right. But currently it would require do a lot of changes in all components bakefiles which would then turn useless as soon as future versions of bakefile are out. So I prefer to make the Big Step in wxCode only when I'm sure that they will be permanent changes ;) > Do you have any idea how we can speed up the patches for bakefile? maybe reporting that the patch worked for you could help... e.g.: http://sourceforge.net/tracker/index.php?func=detail&aid=1376223&group_id=83016&atid=568031 > Is there only a time problem, or are there other issues? basically, it's a time problem of Vaclav. He said he won't give me CVS (or better SVN now) access because my patches often needs fixes before being applied. And that's true :( Sometimes is very difficult to foresee all situations where some code could be used... Francesco |
|
From: k. h. <kla...@nl...> - 2006-03-06 12:54:15
|
Francesco Montorsi wrote: > >> Anyway, i think batch build is the only feasible way to work with the >> bakefile generated project files on VC. > > I've never completely understood this: why do you need to build more > than one configuration with MSVC projects ? > For testing or for development or both ? I would prefer to build only one configuration like in Cmake their is the ALLBuild target, which buils all othere target for the active configuration set to the ALLBuild target. The problem is that if you use wx project files, their is no such overall target. So all seperate targets have to be set by hand to a certain active target, this is bad if there are many. So one goes to batch build, and selects the configurations of all targets which need to be build. No that is doable, although also not ideal, since there are many flavours for each target, you best deselect all flavours for all targets first, and next select the release and debug multilib targets, and build those for all targets. (The trick to deselect all, is selecting the first and Shift select the last and press the space bar) > To test if a project compiles and works in all configs I think it's > best to use command line makefiles where you can script all builds; > for development I usually use IDE too but I always select 1 config and > I've never used batch builds. As i explained above, if there are many targets, how do you set all seperate targets right. Testing using makefiles is oke, but of course the project files need to work too. Also i see no reason why i need to type (n)make first on the command line and next open a project file to start developing where this is also part of the project file. I only use project files when i can ;-) > >> > yes, you're right. > But currently it would require do a lot of changes in all components > bakefiles which would then turn useless as soon as future versions of > bakefile are out. So I prefer to make the Big Step in wxCode only when > I'm sure that they will be permanent changes ;) I think we better mention this in the install.html, because it is confusing. So we must tell that wxstedit needs to be compiled in only one flavour( debug or release and what about the rest? ). And that only this flavours sshould be used in wxLua too. The other make no sence, even when using makefile right? Because using a debug wxstedit in a release wxLua is also wrong. > >> Do you have any idea how we can speed up the patches for bakefile? > > maybe reporting that the patch worked for you could help... e.g.: > > http://sourceforge.net/tracker/index.php?func=detail&aid=1376223&group_id=83016&atid=568031 > Did it :-)) > > >> Is there only a time problem, or are there other issues? > > basically, it's a time problem of Vaclav. He said he won't give me CVS > (or better SVN now) access because my patches often needs fixes before > being applied. And that's true :( > Sometimes is very difficult to foresee all situations where some code > could be used... That i can understand. But not having time was for me the excuse to give many people access to wxArt2D. No progress is worse then solving a problem here and there when it pops up. Go with the flow is my moto, and it pays off, does it not ;-) Klaas -- Unclassified |
|
From: Francesco M. <f18...@ya...> - 2006-03-05 10:30:29
|
klaas.holwerda ha scritto: > John Labenski wrote: >> On 3/4/06, klaas.holwerda >> <kho...@xs...> wrote: >> >>> And indeed app_wxluaedit app crashes in the class RTTI initalization >>> stuff again. >>> This is for sure because of the warning below. It must be somewhere >>> solved in bakefile. >>> >>>> --------------------Configuration: wxstedit - Win32 >>>> Debug-------------------- >>>> Linking... >>>> LINK : warning LNK4098: defaultlib "MSVCRTD" conflicts with use of >>>> other libs; use /NODEFAULTLIB:library >>>> >> >> I think this is because you have compiled wxStEdit in RELEASE? >> Unfortunately the wxStEdit build files only output to a single dir so >> you have to completely! clean it out and rebuild it. >> > No this should not be the case, i have a steditd.lib and a stedit.lib. > And i used batch build. > BUT it looks there is something not right. Since if i just force the > active configuration to build in debug, and rebuild all, > i can also run app_wxluaedit (after a rebuild) without problem. > At least what i saw in wxLua is that stedit.lib is linked always, i > changed it by hand to use wxsteditd.lib. > But looking at the size of wxsteditd.lib and wxstedit.lib they are eqaul > ( binary too ). > I am confused. I'm not sure how batch builds work but as John said, wxStEdit object files always go in the same folder so, unless MSVC does a 'clean project' command between two builds automatically, the batch builds are going to overlap... I'll check it in MSVC asap! Francesco |
|
From: Francesco M. <f18...@ya...> - 2006-03-05 22:50:38
|
[sending 2nd time - Gmane did not get the first message]
John Labenski ha scritto:
> I'm just using the wxCode bakefiles and I don't think there's a way to
> separate the output of the build files? Francesco, is that right? I've
> used the bakefiles for your projects as a starting point, but maybe
> I've missed something.
it's possible but not that elegant:
<set var="POSTFIX">
<if cond="WX_SHARED=='0'">_lib</if>
<if cond="WX_SHARED=='1'">_dll</if>
</set>
<if cond="FORMAT!='autoconf'">
<set var="BUILDDIR">$(FORMAT)$(WXLIBPOSTFIX)$(POSTFIX)</set>
</if>
I plan to revolutionate all wxCode bakefiles as soon as my patches are
integrated in bakefile. Then, to setup a 'standard' component (i.e. a
component using standard folders like src/ and include/) only few lines
will be necessary in component's bakefiles to setup a powerful build
system like the one we currently have in wxLua ;)
Francesco
|
|
From: klaas.holwerda <kho...@xs...> - 2006-03-06 19:03:40
|
Francesco Montorsi wrote: > it's possible but not that elegant: > > > <set var="POSTFIX"> > <if cond="WX_SHARED=='0'">_lib</if> > <if cond="WX_SHARED=='1'">_dll</if> > </set> > <if cond="FORMAT!='autoconf'"> > <set var="BUILDDIR">$(FORMAT)$(WXLIBPOSTFIX)$(POSTFIX)</set> > </if> Maybe it is better to still do this one only for wxstedit for the moment, i think it will prevent a lot of confusion. Klaas |
|
From: Francesco M. <f18...@ya...> - 2006-03-05 10:10:23
|
John Labenski ha scritto:
> I'm just using the wxCode bakefiles and I don't think there's a way to
> separate the output of the build files? Francesco, is that right? I've
> used the bakefiles for your projects as a starting point, but maybe
> I've missed something.
it's possible but not that elegant:
<set var="POSTFIX">
<if cond="WX_SHARED=='0'">_lib</if>
<if cond="WX_SHARED=='1'">_dll</if>
</set>
<if cond="FORMAT!='autoconf'">
<set var="BUILDDIR">$(FORMAT)$(WXLIBPOSTFIX)$(POSTFIX)</set>
</if>
I plan to revolutionate all wxCode bakefiles as soon as my patches are
integrated in bakefile. Then, to setup a 'standard' component (i.e. a
component using standard folders like src/ and include/) only few lines
will be necessary in component's bakefiles to setup a powerful build
system like the one we currently have in wxLua ;)
Francesco
|
|
From: Francesco M. <f18...@ya...> - 2006-03-06 22:52:12
|
klaas.holwerda ha scritto: > Francesco Montorsi wrote: >> it's possible but not that elegant: >> >> >> <set var="POSTFIX"> >> <if cond="WX_SHARED=='0'">_lib</if> >> <if cond="WX_SHARED=='1'">_dll</if> >> </set> >> <if cond="FORMAT!='autoconf'"> >> <set var="BUILDDIR">$(FORMAT)$(WXLIBPOSTFIX)$(POSTFIX)</set> >> </if> > Maybe it is better to still do this one only for wxstedit for the > moment, i think it will prevent a lot of confusion. you're right; I've committed this change in wxCode CVS repo. John, could we make a new release (tarball+zip) of wxStEdit before wxLua is out so to avoid problems to our users ? Francesco |
|
From: John L. <jla...@gm...> - 2006-03-06 23:31:21
|
On 3/6/06, Francesco Montorsi <f18...@ya...> wrote:
> klaas.holwerda ha scritto:
> > Francesco Montorsi wrote:
> >> it's possible but not that elegant:
> >>
> >>
> >> <set var=3D"POSTFIX">
> >> <if cond=3D"WX_SHARED=3D=3D'0'">_lib</if>
> >> <if cond=3D"WX_SHARED=3D=3D'1'">_dll</if>
> >> </set>
> >> <if cond=3D"FORMAT!=3D'autoconf'">
> >> <set var=3D"BUILDDIR">$(FORMAT)$(WXLIBPOSTFIX)$(POSTFIX)</set>
> >> </if>
> > Maybe it is better to still do this one only for wxstedit for the
> > moment, i think it will prevent a lot of confusion.
> you're right; I've committed this change in wxCode CVS repo.
>
> John, could we make a new release (tarball+zip) of wxStEdit before wxLua
> is out so to avoid problems to our users ?
Yes, I was going to do a release last week, good thing I didn't. :)
Thanks,
John Labenski
|
|
From: Francesco M. <f18...@ya...> - 2006-03-05 22:30:37
|
[sending 2nd time - Gmane did not get the first message] klaas.holwerda ha scritto: > Hi, > > I thought i do a last test with VC6 ( only debug and release multilib ). > > I see with wxStEdit from wxCode CVS, still this problem, i think this is > the same as we had some time ago. > If it is already introduced here, later on in wxLua the problem will > stay, and eventually in wxArt2D it became a real problem. > Francesco how did you solve it that time? Better do it here too. sincerely I don't remember how I solved it :( However, looking at DSP files for both wxLua and wxStEdit, I see that there are no /NODEFAULTLIB switches inside them. I thought the problem last time was because of the *presence* of those switches. For me it's a problem solve these 'bugs' because I don't have easy access to Windows now that I work on linux only... I'll let you know, Francesco |
|
From: Francesco M. <f18...@ya...> - 2006-03-05 10:00:26
|
klaas.holwerda ha scritto: > Hi, > > I thought i do a last test with VC6 ( only debug and release multilib ). > > I see with wxStEdit from wxCode CVS, still this problem, i think this is > the same as we had some time ago. > If it is already introduced here, later on in wxLua the problem will > stay, and eventually in wxArt2D it became a real problem. > Francesco how did you solve it that time? Better do it here too. sincerely I don't remember how I solved it :( However, looking at DSP files for both wxLua and wxStEdit, I see that there are no /NODEFAULTLIB switches inside them. I thought the problem last time was because of the *presence* of those switches. For me it's a problem solve these 'bugs' because I don't have easy access to Windows now that I work on linux only... I'll let you know, Francesco |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X