Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.10.0
    • Fix Version/s: 0.10.0
    • Component/s: Build
    • Labels:
      None

      Description

      On Mar 16, 2005, at 7:44 AM, Peter Steiner wrote: (log4cxx-dev)

      > Hello!
      >
      > I'm trying to integrate log4cxx into a new Visual Studio 2003 project
      > and tried to use the static library.
      >
      > Using the current CVS head (from 2005-03-15 16:00GMT), I have found
      > several problems:
      >
      > - INSTALL: typo in Build options description:
      > "-Dlibtype" instead of "-Dlib.type"
      > - During "ant -Dlib.type=static": build-shortsocketserver fails
      > (I have not investigated this as the library itself is built at this
      > time)
      > - msvc/static/static.cpp doesn't exist anymore,
      > but it is still referenced in config_msvc.h.in and portability.h
      > This leads to linker errors not finding ForceSymbolReferences.
      > After removing these #pragma comment lines in both files, I was
      > able to link and run my (very simple) test program.
      >
      > Is the static library still supported or are there reasons to avoid the
      > static library other than to save space?
      >

      Thanks for the report. Any breakage of the static build was due to
      neglect, not intent, and it is likely broken on all platforms. I'll
      see what I can do to get it functional again.

      If you are calling log4cxx from a DLL, then it would be beneficial to
      use the log4cxx.dll so both the application executable and application
      dll could share the same log system.

        Activity

        Hide
        Curt Arnold added a comment -

        A recurring problems with static build has been default initialization reporting that built-in classes like "FileAppender" are not recognized. This occurred since default initialization was triggered on the first getLogger call which when appearring in a static member initialization could occur before all the classes had been registered. Changes committed on 13 May 2005 defer the default configuration until the first evauation of Hierarchy.isDisabled() which should occur during the first log request and hopefully after all the classes have been registered. The problem was not seen with shared libs since all the static variable initializations in log4cxx.so would occur before the initializations in the calling lib.

        Show
        Curt Arnold added a comment - A recurring problems with static build has been default initialization reporting that built-in classes like "FileAppender" are not recognized. This occurred since default initialization was triggered on the first getLogger call which when appearring in a static member initialization could occur before all the classes had been registered. Changes committed on 13 May 2005 defer the default configuration until the first evauation of Hierarchy.isDisabled() which should occur during the first log request and hopefully after all the classes have been registered. The problem was not seen with shared libs since all the static variable initializations in log4cxx.so would occur before the initializations in the calling lib.
        Hide
        scott mcfadden added a comment -

        I noticed that I can run the log4cxx / ant build script and it builds correctly for a shared library. When I specify a static build, no errors, but you end up with a empty lib file which will fail to link with client code later on.

        I noticed in jira this was reported in 2005. Has this been fixed or is it still an issue?

        VC2008 RTM

        Log4cxx Trunk Revision 606117

        thanks

        Show
        scott mcfadden added a comment - I noticed that I can run the log4cxx / ant build script and it builds correctly for a shared library. When I specify a static build, no errors, but you end up with a empty lib file which will fail to link with client code later on. I noticed in jira this was reported in 2005. Has this been fixed or is it still an issue? VC2008 RTM Log4cxx Trunk Revision 606117 thanks
        Hide
        Curt Arnold added a comment -

        I didn't see the empty lib, but I did have a failure in testcase2 due to DOMConfigurator not being registered. Added DOMConfigurator and PropertyConfiguration to the list of forcibly registered classes in Class::registerClasses. Marking as closed, if you still have issues, please file a new report (or reopen this one if prior to 0.10.0 release).

        Show
        Curt Arnold added a comment - I didn't see the empty lib, but I did have a failure in testcase2 due to DOMConfigurator not being registered. Added DOMConfigurator and PropertyConfiguration to the list of forcibly registered classes in Class::registerClasses. Marking as closed, if you still have issues, please file a new report (or reopen this one if prior to 0.10.0 release).

          People

          • Assignee:
            Curt Arnold
            Reporter:
            Curt Arnold
          • Votes:
            3 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development