Hi,
here is some feedback regarding the build of core and gui of 1.3.3-rc2
with Visual C++ 2008. Long story short, this finally succeeded, but
after some efforts and changes.
I selected the flavour I was interested in,
vs2005-windows-i386-nothreads.zip (for the config files only, as I am
using custom-made .sln/.vcproj files).
- core_init.h includes agar/begin.h whereas begin.h is at the root of
the extracted archive. Thus a fix is including begin.h directly; same
thing for close.h. However lots of includes are relative to an "agar"
directory, thus I temporarily renamed the "agar-1.3.3-rc2" base
directory to "agar" and added its parent directory in the include path.
I did not understand why an "agar" directory was mentioned as such (the
library is not expected to be built against its already installed
headers, is it?)
- config/have_dlopen.h, config/have_dlfcn_h.h, etc. were needed by
core/dso.c but were not available in the vs2005 archives (I removed the
#include for the test)
- still in dso.c, line 170, there is most probably a bug (assignment
written as a test)
- there is a warning in core/prop.c, lines 47 and 64, due to different
const qualifiers
With these changes a non-empty .dll and .lib could be produced for
ag_core. However some symbols were still lacking, at least the ones for
all the exported variables (ex: agConfig), whereas the functions were
available. This was due to the use of the Agar DECLSPEC define, that
should, in my opinion, be improved, as explained later in this mail.
Why are there includes of gui headers from core files ? (ex:
core/config.c including gui/view.h, same thing for core/rcs.c). Isn't
gui meant to depend on core, and not the opposite? Moreover these
includes can be removed without breaking the build of core! Finally I
found other includes of gui from core that were actually necessary. Thus
core and gui are mutually dependent, as I understand now.
Why AG_ProcessEvent, that depends on SDL, ends up declared in core
(core/event.h) whereas defined in gui (gui/view.c) ? Same thing about
AG_WriteColor (core/load_color.c). Maybe a nicer and cleaner separation
could be at least to have only gui depending on SDL?
Another concern is gui using its own extern declarations of core symbols
instead of including the core headers: when building gui, I think that
the DECLSPEC define should resolve into dllimport for core symbols and
dllexport for gui symbols. The same symbol cannot be used for both,
which is the explanation for the unresolved externals for agConfig and
al that I already mentioned.
My suggested fix would be to use respectively AGAR_CORE_DLL and
AGAR_GUI_DLL defines instead of DECLSPEC, which would be defined on a
per-library basis.
More precisely:
- in core project, AGAR_CORE_DLL would be __declspec(dllexport) and
(since there is a two-way dependency) AGAR_GUI_DLL would be
__declspec(dllimport)
- in gui project, AGAR_CORE_DLL would be __declspec(import) and
AGAR_GUI_DLL would be __declspec(dllexport)
- and so on
Explicit (direct) extern declarations of symbols coming from other
libraries would then be replaced by #include of their corresponding
headers. This would require adding include guards in headers (ex:
event.h), to prevent multiple declarations.
Finally, in core/snprintf.h and other core headers, AG_Snprintf,
AG_Vsnprintf and AG_Vasprintf had no extern nor DLL export declaration,
whereas they are widely used by gui.
I applied all these suggestions to core and gui and was able to compile
and link them flawlessly. At last gui could resolve all the symbols it
needed from core, thus I believe the build is ok now.
Julien, I can send you off-list a zip archive containing the modified
sources and project files, and the resulting .LIB/.DLL, for core and for
gui.
Best regards,
Olivier.
Julien Nadeau a écrit :
> Hi. Sorry for the late reply,
>
> On Fri, Oct 03, 2008 at 03:27:06PM +0200, Olivier Boudeville wrote:
>
>> Hi Julien,
>>
>> thanks for your answer. Below are a few precisions:
>>
>> Julien Nadeau a ?crit :
>>
>>> On Fri, Oct 03, 2008 at 01:47:55PM +0200, Olivier Boudeville wrote:
>>>
>>>
>>>> Hi again,
>>>>
>>>> I am still stuck with the Visual 2008 build, still no luck figuring out
>>>> how a .LIB could be generated from the Agar 1.3.2 sources. Any hint on
>>>> that topic or the others I raised two months ago?
>>>>
>>> As I said in my original response, Visual Studio 2008 is a defective,
>>> non-standard C compiler. It fails because of an empty macro argument.
>>> The workaround would be trivial - remove the first argument to
>>> AG_TAILQ_HEAD(), but instead I'd recommend that you try a supported
>>> version of Visual Studio, such as 2005.
>>>
>>>
>> I think you confused my question with the one asked by ADI64: I am not
>> stuck because of a macro, I just would like to understand how, with a
>> Microsoft compiler (be it 2005 or 2008) the .LIB can be produced.
>>
>
> Oh, I just assumed it was the same issue. So you were able to compile
> Agar successfully under VC2008 without any problems, other than the
> missing .LIB?
>
>
>> Obviously it must work (at least with 2005), but I thought the two
>> methods for having a .LIB generated was to use export declaration in
>> header files (__declspec( dllexport ) etc.) or to use a .def file. I
>> could not see either of them in Agar files (I must have overlooked
>> something), so any hint about the method used would help me a lot.
>>
>
> Yes, for some reason that was not needed with 2005. The headers in the
> source .zip (but not the tar.gz) are now generated to include these
> declarations. Please give it a try:
>
> http://beta.hypertriton.com/agar/agar-1.3.3-rc2.zip
>
>
>> Regarding the 2005 vs 2008 issue, I think too these compilers are far
>> from perfect, but I was hoping 2008 could be (even marginally) better
>> than 2005. I used it successfully to build all my pre requisites other
>> than Agar (including SDL, libjpeg, zlib , libpng, SDL_image, SDL_gfx,
>> freetype, SDL_ttf, libogg, libvorbis, SDL_mixer) so I felt like trying
>> it on Agar and - if needed - contributing back some patches or project
>> files. Currently I can generate the corresponding DLL but sadly no LIB
>> is produced.
>>
>
> Please try again with 1.3.3-rc2 and let me know if the LIB is produced
> as expected.
>
>
>>>> On the Linux side, there is a typo in include/agar/agar/core/rcs.h. No
>>>> comma should exist after AG_RCS_DESYNCH, the compiler complains:
>>>>
>>>> enum ag_rcs_status {
>>>> AG_RCS_ERROR, /* Status unavailable */
>>>> AG_RCS_UNKNOWN, /* Not on the repository */
>>>> AG_RCS_UPTODATE, /* Working copy = last rev and checksum matches */
>>>> AG_RCS_LOCALMOD, /* Working copy = last rev and checksum mismatch */
>>>> AG_RCS_DESYNCH, /* Working copy < last rev */
>>>> };
>>>>
>>> Out of curiosity, what compiler are you using? I'll remove it, but I've
>>> never had any problems with this code, it has been there for years and
>>> tested under many different compilers.
>>>
>>>
>> On Linux I am using a vanilla gcc 4.2.3 from Ubuntu, with following
>> options:
>>
>> -g -ggdb -O0 -fno-inline -Wall -Werror -Woverloaded-virtual -W
>> -Wfloat-equal -Wundef -Wendif-labels -Wshadow -Wpointer-arith
>> -Wcast-qual -Wcast-align -Wwrite-strings -Wconversion -Wsign-compare
>> -Wmissing-format-attribute -Wredundant-decls -Wno-unused-parameter
>> -Wno-unknown-pragmas -Wno-long-long -ansi -pedantic-errors
>>
>
> Thanks, I'll give -pedantic-errors a try.
>
>
>> All the pre requisites I listed can be built with that same flags, but I
>> think I will have to relax them a bit, since Agar uses C99-variadic
>> macros (ex: #define AG_TableviewRowAdd(...)
>> AG_TableviewRowAddFn(__VA_ARGS__, -1) in tableview.h).
>>
>
> That's ok, this was the only instance of a variadic macro in Agar. It was
> a previously undocumented interface and it was removed in 1.3.3.
>
>
>
>
_______________________________________________
Agar mailing list
[email protected]
http://libagar.org/lists.html
