Loading ...
Sorry, an error occurred while loading the content.

Re: More VC++ 6 Confusion (MFC libs)

Expand Messages
  • isabellemus
    The import/export declaration isn t that hard (see below) #if defined(WIN32) && defined(_MSC_VER) #if defined(BUILD_ANTLR_DLL) #define DllImpExp
    Message 1 of 10 , Jan 1, 2002
    • 0 Attachment
      The import/export declaration isn't that hard (see below)

      #if defined(WIN32) && defined(_MSC_VER)
      #if defined(BUILD_ANTLR_DLL)
      #define DllImpExp __declspec(dllexport)
      #else
      #define DllImpExp __declspec(dllimport)
      #endif /* BUILD_ANTLR_DLL */
      #else /* WIN32 && _MSC_VER */
      #define DllImpExp
      #endif

      where BUILD_ANTLR_DLL should be defined when building the DLL. The
      pain is modifying the class declarations you want exported to

      DllImpExp MyClass {} ;

      Isabelle

      --- In antlr-interest@y..., "jsrs701" <jsrs701@y...> wrote:
      > --- In antlr-interest@y..., "isabellemus" <meta.logix@p...> wrote:
      > > Hi,
      > >
      > > Try using the static antlr library, works for me (use the LIB
      > project
      > > in MSCV6-dll directory).
      > >
      > > I have a different problem with using the dll : I cannot get MSVC
      > to
      > > generate an import library (don't have a .def file), and cannot
      > find
      > > any export declarations in the source.
      > >
      > > Isabelle
      >
      > The import library issue is a messy one. In one of the contrib
      items
      > for building an ANTLR DLL, it mentions a replacement file
      > (config.hpp) that contains a macro called DLLEXPORT.
      Unfortunately,
      > I can't find any trace of this file, nor the macro. Hm.
      >
      > You probably don't want to do a .def file, though, since you'll
      have
      > to deal with the messy C++ munged symbols. Ugh. Better to stick
      > with the dllimport and dllexport declspecs on the classes
      themselves.
      >
      > On second thought, anybody know where that config.hpp file got off
      > to? Ter, Ric? It's the file Michael Richter mentions in his
      README.
      >
      > JSRS
    • kemmerzehl
      The problem I had was actually incredibly simple, and I do feel a little silly now. The project files JSRS posted were using the single thread runtime
      Message 2 of 10 , Jan 1, 2002
      • 0 Attachment
        The problem I had was actually incredibly simple, and I do feel a
        little silly now. The project files JSRS posted were using the single
        thread runtime libraries to build the antlr lib, and this was fine
        for projects NOT using MFC because by default they are also use the
        single thread runtime libraries. When I create a project with MFC
        support, however, it switches to using the multi thread runtime
        libraries. Trying to link these with the single threaded antlr
        library was causing all sorts of compatibility problems. Building
        another set of the antlr libs using the /MT and /MTd (instead of /ML
        and /MLd) flags to link with projects using the multithreaded runtime
        libraries solved the problem.
        Simple.
        ..and luckily i didnt rip ALL of my hair out.

        Thanks for your input and I apoligise for confusing you all with such
        a simple issue.
        -Kemmerzehl

        --- In antlr-interest@y..., "kemmerzehl" <malitrait@s...> wrote:
        > Hi,
        > I do hate to add to your list of confused VC++ user messages but
        > I've followed the steps from your existing discussions/literature
        and
        > I'm still having some problems. It appears this particular issue
        has
        > not yet been addressed although it seems like it would be a
        > common problem so I do apologise if I've missed something.
        > Anyway, here's the problem. Quite simply, the ANTLR and MFC libs
        > just wont work for me together - I get link errors. I've built my
        > ANTLR lib files according to JSRS's 'How To', and by themselves
        they
        > work well. If I use VC++ to create a 'Win32 Console Application'
        and
        > do NOT include MFC support, then add the generated calc example
        files
        > and add the ANTLR library, everything compiles links and runs fine.
        > If, however, I do the same thing only I DO include MFC support (and
        > remembering to take off the /Yu"stdafx.h" flag), I get the
        following
        > link errors:
        >
        > LIBC.lib(cfout.obj) : error LNK2005: ___dtold already defined in
        > libcmt.lib(cfout.obj)
        > LIBC.lib(crt0dat.obj) : error LNK2005: __cinit already defined in
        > libcmt.lib(crt0dat.obj)
        > LIBC.lib(crt0dat.obj) : error LNK2005: _exit already defined in
        > libcmt.lib(crt0dat.obj)
        > LIBC.lib(crt0dat.obj) : error LNK2005: __exit already defined in
        > libcmt.lib(crt0dat.obj)
        > LIBC.lib(crt0dat.obj) : error LNK2005: __cexit already defined in
        > libcmt.lib(crt0dat.obj)
        > ..etc.
        >
        > One rather odd thing is that I can get the _debug_ build to work
        > (for the calc example) if I link statically to MFC and use the /MT
        > flag instead of /MTd(default for debug builds). These flags
        represent
        > the "Multithreaded" and "Debug Multithreaded" runtime libraries,
        > available in the "Code Generation" dropdown section of the "C++"
        tab
        > in Project -> Settings. This however does not fix the problem for
        the
        > release build, I even tried using JSRS's debug version of the ANTLR
        > library with the release build (using /MT) and I still got link
        > errors. Also, I could not get rid of the link errors at all for the
        > project im working on (with either build).
        > All of this is purely trial and error for me as I've never had to
        > deal with third-party libraries before. I hope some of the info
        I've
        > provided can be of use and that somebody out there has experienced
        > this linking problem before and knows how to fix it. Either way,
        I'm
        > going to keep ripping my hair out trying to fix it, if I find a
        > solution I'll post it.
        >
        > Thanks,
        > -Kemmerzehl
      • Terence Parr
        ... Can anybody summarize the changes to the FAQ I should make? http://www.jguru.com/faq/view.jsp?EID=203548 Ter -- Chief Scientist & Co-founder,
        Message 3 of 10 , Jan 1, 2002
        • 0 Attachment
          On Tuesday, January 1, 2002, at 10:02 AM, kemmerzehl wrote:

          > The problem I had was actually incredibly simple, and I do feel a
          > little silly now. The project files JSRS posted were using the single
          > thread runtime libraries to build the antlr lib, and this was fine
          > for projects NOT using MFC because by default they are also use the
          > single thread runtime libraries. When I create a project with MFC
          > support, however, it switches to using the multi thread runtime
          > libraries. Trying to link these with the single threaded antlr
          > library was causing all sorts of compatibility problems. Building
          > another set of the antlr libs using the /MT and /MTd (instead of /ML
          > and /MLd) flags to link with projects using the multithreaded runtime
          > libraries solved the problem.
          > Simple.
          > ..and luckily i didnt rip ALL of my hair out.

          Can anybody summarize the changes to the FAQ I should make?

          http://www.jguru.com/faq/view.jsp?EID=203548

          Ter
          --
          Chief Scientist & Co-founder, http://www.jguru.com
          Creator, ANTLR Parser Generator: http://www.antlr.org
        • Ric Klaren
          Hi, ... The DLL export stuff is already in antlr-2.7.2a1. It s only called ANTLR_API now (used a different patch than the one in contrib). ... Hmmm strange I
          Message 4 of 10 , Jan 3, 2002
          • 0 Attachment
            Hi,

            On Mon, Dec 31, 2001 at 11:52:04PM -0000, jsrs701 wrote:
            > > I have a different problem with using the dll : I cannot get MSVC to
            > > generate an import library (don't have a .def file), and cannot find
            > > any export declarations in the source.
            > >
            > > Isabelle

            > The import library issue is a messy one. In one of the contrib items
            > for building an ANTLR DLL, it mentions a replacement file
            > (config.hpp) that contains a macro called DLLEXPORT. Unfortunately,
            > I can't find any trace of this file, nor the macro. Hm.

            The DLL export stuff is already in antlr-2.7.2a1. It's only called
            ANTLR_API now (used a different patch than the one in contrib).

            > You probably don't want to do a .def file, though, since you'll have
            > to deal with the messy C++ munged symbols. Ugh. Better to stick
            > with the dllimport and dllexport declspecs on the classes themselves.
            >
            > On second thought, anybody know where that config.hpp file got off
            > to? Ter, Ric? It's the file Michael Richter mentions in his README.

            Hmmm strange I cannot recall removing the file. Then again I had planned on
            including the DLL build in 2.7.2. That was before running into a whole lot
            of trouble with MSVC6. It really barfs on a dll build.

            It refuses to compile/link. My impression (going on the fuzzy error
            messages it is giving) is that it does not support linking STL stuff into
            DLL's (can this be true?? at least I'm missing the dllexport stuff in the
            stl headers..)??

            Doing explicit instantiations ala (with some msvc extension):

            #if defined(_MSC_VER) && !defined(__ICL) // Microsoft Visual C++
            extern template class ANTLR_API ANTLR_USE_NAMESPACE(std)vector<int>;
            #endif

            Seems not to work?

            I'm not a MSVC expert so I'm hoping some more knowledgeable MSVC6 hacker
            may want to fix the toplevel .dsw .dsp files. It may require adding a few
            directories to the lib/cpp tree for the .dll and the .lib build.

            Cheers,

            Ric
            --
            -----+++++*****************************************************+++++++++-------
            ---- Ric Klaren ----- klaren@... ----- +31 53 4893722 ----
            -----+++++*****************************************************+++++++++-------
            Time what is time - I wish I knew how to tell You why - It hurts to know -
            Aren't we machines - Time what is time - Unlock the door
            - And see the truth - Then time is time again
            From: 'Time what is Time' by Blind Guardian
          • isabellemus
            Hi, Concerning stl in dll builds : in MSVC, template classes should completely be defined in headers (i.e. everything inline). This is what stl does. So the
            Message 5 of 10 , Jan 4, 2002
            • 0 Attachment
              Hi,

              Concerning stl in dll builds : in MSVC, template classes should
              completely be defined in headers (i.e. everything inline). This is
              what stl does.
              So the actual template expansion will be done when someone (either
              building the dll or trying to use it) includes the dll's headers. So
              I don't think stl is the problem.
              The 2.7.2a1 sources don't compile at all, though. I spent an hour
              trying to figure out what's wrong, and failed. The preprocessor
              output looks OK, the macros look OK, and MSVC complains about every
              single class.

              Isabelle

              --- In antlr-interest@y..., Ric Klaren <klaren@c...> wrote:
              > Hi,
              >
              > On Mon, Dec 31, 2001 at 11:52:04PM -0000, jsrs701 wrote:
              > > > I have a different problem with using the dll : I cannot get
              MSVC to
              > > > generate an import library (don't have a .def file), and cannot
              find
              > > > any export declarations in the source.
              > > >
              > > > Isabelle
              >
              > > The import library issue is a messy one. In one of the contrib
              items
              > > for building an ANTLR DLL, it mentions a replacement file
              > > (config.hpp) that contains a macro called DLLEXPORT.
              Unfortunately,
              > > I can't find any trace of this file, nor the macro. Hm.
              >
              > The DLL export stuff is already in antlr-2.7.2a1. It's only called
              > ANTLR_API now (used a different patch than the one in contrib).
              >
              > > You probably don't want to do a .def file, though, since you'll
              have
              > > to deal with the messy C++ munged symbols. Ugh. Better to stick
              > > with the dllimport and dllexport declspecs on the classes
              themselves.
              > >
              > > On second thought, anybody know where that config.hpp file got
              off
              > > to? Ter, Ric? It's the file Michael Richter mentions in his
              README.
              >
              > Hmmm strange I cannot recall removing the file. Then again I had
              planned on
              > including the DLL build in 2.7.2. That was before running into a
              whole lot
              > of trouble with MSVC6. It really barfs on a dll build.
              >
              > It refuses to compile/link. My impression (going on the fuzzy error
              > messages it is giving) is that it does not support linking STL
              stuff into
              > DLL's (can this be true?? at least I'm missing the dllexport stuff
              in the
              > stl headers..)??
              >
              > Doing explicit instantiations ala (with some msvc extension):
              >
              > #if defined(_MSC_VER) && !defined(__ICL) // Microsoft Visual C++
              > extern template class ANTLR_API ANTLR_USE_NAMESPACE(std)vector<int>;
              > #endif
              >
              > Seems not to work?
              >
              > I'm not a MSVC expert so I'm hoping some more knowledgeable MSVC6
              hacker
              > may want to fix the toplevel .dsw .dsp files. It may require adding
              a few
              > directories to the lib/cpp tree for the .dll and the .lib build.
              >
              > Cheers,
              >
              > Ric
              > --
              > -----
              +++++*****************************************************+++++++++---
              ----
              > ---- Ric Klaren ----- klaren@c... ----- +31 53 4893722 ----
              > -----
              +++++*****************************************************+++++++++---
              ----
              > Time what is time - I wish I knew how to tell You why - It hurts
              to know -
              > Aren't we machines - Time what is time - Unlock the door
              > - And see the truth - Then time is time again
              > From: 'Time what is Time' by Blind Guardian
            Your message has been successfully submitted and would be delivered to recipients shortly.