[wxlua-users] LNK4006 (was Re: build system update)

[Francesco M. <f18...@ya...>]

Hi,

John Labenski ha scritto:
> These warnings are back, I'm pretty sure I didn't get them a week ago
> and I don't understand what the problem could be. I'm using wxWidgets
> 2.6 from CVS and MS Visual Studio 6.
I get them also with MS VisualStudio 7.1 with wxMSW 2.8...


> wxlua_msw26d_lua.lib(lapi.obj) : warning LNK4006: _lua_ident already
> defined in wxlua_msw26d_wxlua.lib(lapi.obj); second definition ignored
...
> 
> and so on for the other libs. Any ideas why this is happening again?
I've searched the wxlua-users mailing list but I couldn't find any reference 
(except in the very latest mails) to LNK4006 warnings - did we ever get them before?

> I
> can't understand why the const char lua_ident[] = {...} inside of
> lapi.c only (not in header at all) could possibly have a problem since
> mod_wxbind Debug Multilib doesn't link to anything!
I can't understand that too. I've checked and unless my eyes are lying to me, 
all the DSP are using the same build settings.
I've searched the net but I couldn't find any good hint. It's strange: the 
linker shouldn't run at all when creating a static lib!


>>> In the last  i see now wxlua, this is why we once decide to use wxlua_
>>> as a sort of name space.
>>> I am not sure why wxCode prefers it different.
>> it's not a preference - just a "bug". Definitively the <wxlike-lib> tag
>> should take in account a prefix as other wxlike-* tags do.
> 
> Maybe an additional <wxlike-prefix-lib> that has the prefix could be
> added. The <wxlike-lib> code is pretty small so it might not be too
> much bloat. See below, that idea sounds pretty good and very simple.
sure, adding a new tag like <wxlike-prefix-lib> would be feasible but I hope 
that it won't even be needed - as soon as wx2.8.0 will be released I hope to get 
the wxpresets patch applied (and it contains a working wxlike-lib tag with 
prefix support).

> 
>>> Anyway it seems that all contrib stuff is in the from wxmsw28_nameofcontrib.
>>> So looking at it like that maybe we should have:
>>>
>>> wxmsw28d_wxlua_lua.lib
>>> wxmsw28d_wxlua_bind.lib
>>> wxmsw28d_wxlua_debug.lib
>>> wxmsw28d_wxlua_socket.lib
>>> etc.
>> hmmm, I don't see any great advantage over current naming, except that
>> this is backward-incompatible for all ours wxLua users which should
>> probably need to update their makefiles/project files without any real
>> need (wxlike-lib tag must be fixed, not our naming rules).
> 
> I don't think we have to worry about backwards compatibility too much.
> We have a small user base and hopefully things will be settled once
> and for all after this.
> 
> I DO like this idea and think it's just as well. I'd keep the wx in
> the second name though to be clear about what the lib is really for
> since wxluadebug/socket are not generic debug/socket libs, but only
> work with wxlua.
> 
> wxlua_msw26d_wxlua_lua.lib
> wxlua_msw26d_wxlua_wxbind.lib
> wxlua_msw26d_wxlua_wxbindstc.lib
> wxlua_msw26d_wxlua_wxlua.lib
> wxlua_msw26d_wxlua_wxluadebug.lib
> wxlua_msw26d_wxlua_wxluasocket.lib
sorry but I don't understand why should we repeat "wxlua" twice in the name of 
the libraries: if there's 1 "wxlua" prefix it seems quite clear to me that the 
debug/sockets libs are not "generic" but wxlua-only.

> 
> In any case, do whatever you think is best Francesco.
sorry but I don't see what's wrong with current naming - I'd just keep it as in 
current way...

> ps. The precompiled headers are GREAT! I can't really tell much of a
> difference in MSVC6, but I was thinking about how we could do it and
> wanted to ask if you knew how, but thought it might be too much work.
glad to know they were appreciated - however to speedup even more the 
compilation of wxLua our headers should include a wxLua PCH, just as Klaas 
suggests (see other mail).


Francesco