[llvm-dev] Errors linking with LLVM 5.0 - dump() missing

[Don Hinton via llvm-dev]

Thanks for reporting this.

Looks like this one was missed -- the declaration should have been #ifdef'd
away along with the definition.   A quick grep indicates there are a number
of them that need to be fixed.

Here's the original commit:

commit 88d207542b618ca6054b24491ddd67f8ca397540
Author: Matthias Braun <matze at braunis.de>
Date:   Sat Jan 28 02:02:38 2017 +0000

    Cleanup dump() functions.

    We had various variants of defining dump() functions in LLVM. Normalize
    them (this should just consistently implement the things discussed in
    http://lists.llvm.org/pipermail/cfe-dev/2014-January/034323.html

    For reference:
    - Public headers should just declare the dump() method but not use
      LLVM_DUMP_METHOD or #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
    - The definition of a dump method should look like this:
      #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
      LLVM_DUMP_METHOD void MyClass::dump() {
        // print stuff to dbgs()...
      }
      #endif

    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@293359
91177308-0d34-0410-b5e6-96231b3b80d8

On Mon, Sep 25, 2017 at 1:22 PM, Dibyendu Majumdar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi Martin
>
> On 25 September 2017 at 21:13, Martin J. O'Riordan <MartinO at theheart.ie>
> wrote:
> > Yes, if it is in the interface it would make more sense to have a null
> implementation at the very least.  In my out-of-tree target, I also removed
> them from the interface if the build was for Release to ensure that I got
> compile-time errors to reveal other places I might have otherwise missed.
> >
>
> I assume you now need to create two LLVM builds - a debug build and a
> release build. Then you need to link your own app's debug build /
> release build to the right LLVM build.
>
> On Windows this has to happen anyway due to dependencies on the C
> libraries etc. but on Linux/Mac OSX I never had to until now build a
> debug build of LLVM.
>
> As I mentioned the real problem is that the client has no way of
> knowing how LLVM was built - as there is no #define to flag the
> missing dump() implementation either.
>
> Regards
> Dibyendu
>
>
> >
> > -----Original Message-----
> > From: Dibyendu Majumdar [mailto:mobile at majumdar.org.uk]
> > Sent: 25 September 2017 20:57
> > To: Martin J. O'Riordan <MartinO at theheart.ie>
> > Cc: LLVM Developers <llvm-dev at lists.llvm.org>
> > Subject: Re: [llvm-dev] Errors linking with LLVM 5.0 - dump() missing
> >
> > Hi Martin,
> >
> >
> > On 25 September 2017 at 20:35, Martin J. O'Riordan <MartinO at theheart.ie>
> wrote:
> >> Are you building a Debug or Release version of the compiler?
> >
> > It seems that in Release builds of LLVM 5.0 the dump() implementation is
> absent, although the method is available in the interface. This is plain
> wrong in my view. If the dump() has to be removed then it should not be
> present in the interface.
> >
> >>
> >> I had similar problems a few days ago when I was migrating to v5.0, and
> it turned out that I had calls to some of the dump routines that were not
> guarded by either 'DEBUG(...)' or '#ifndef NDEBUG ... #endif' and I was
> seeing the link failures with a Release build.  These had been there since
> LLVM v3.1 and had never broken before.  There was some clean-up done in the
> sources so that may of the 'dump' routines are enabled only for Debug
> builds, and I fixed these (in my code) by adding these guards.
> >>
> >
> > Well the problem is that there is no obvious way for a client to detect
> whether the dump() implementation is available or not - as it does not
> depend upon the Release/Debug build status of the client, but how LLVM 5.0
> was originally compiled. So the guards you have put are not really going to
> work (that is my finding anyway).
> >
> > Regards
> > Dibyendu
> >
> >>
> >> -----Original Message-----
> >> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> >> Dibyendu Majumdar via llvm-dev
> >> Sent: 25 September 2017 19:41
> >> To: llvm-dev at lists.llvm.org
> >> Subject: [llvm-dev] Errors linking with LLVM 5.0 - dump() missing
> >>
> >> Hi,
> >>
> >> I am finding that my project that previously successfully built with
> versions 3.5 to 4.0 is now failing to link because of missing
> implementation for dump(). Errors I get are:
> >>
> >> Undefined symbols for architecture x86_64:
> >>
> >>   "llvm::Type::dump() const", referenced from:
> >>       ravi::LuaLLVMTypes::dump() in ravi_llvmtypes.cpp.o
> >>       dump_content(lua_State*) in ravi_llvmluaapi.cpp.o
> >>   "llvm::Value::dump() const", referenced from:
> >>       dump_content(lua_State*) in ravi_llvmluaapi.cpp.o
> >>   "llvm::Module::dump() const", referenced from:
> >>
> >> This appears to be a change that is not documented in the release notes
> of 5.0. Please can someone describe what the change is and how I can detect
> whether the dump() implementation is available or not?
> >>
> >> It also seems strange that dump() implementation was removed - surely
> it would have been better ti stub it so that client code does not break?
> >>
> >> Regards
> >> Dibyendu
> >> _______________________________________________
> >> LLVM Developers mailing list
> >> llvm-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> >>
> >
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170925/9ea33b03/attachment.html>