From: Pavel Chupin <pavel.v.chupin@gmail.com>
To: Kai Tietz <ktietz70@googlemail.com>
Cc: Joel Brobecker <brobecker@adacore.com>,
gdb-patches@sourceware.org, "H.J. Lu" <hjl.tools@gmail.com>
Subject: Re: [PATCH] Fix libtool.m4 dlopen lookup for mingw
Date: Tue, 27 Nov 2012 12:17:00 -0000 [thread overview]
Message-ID: <CANwJu18Z_L9MuXy=3d3UTEucBjRmTH_93YwSebHgBm-hzuB=wg@mail.gmail.com> (raw)
In-Reply-To: <CAEwic4Yxu70mRaMnEcx=mYeWTaMaDc83_gFDbk8Tie2G6vHK6g@mail.gmail.com>
On Tue, Nov 27, 2012 at 12:16 PM, Kai Tietz <ktietz70@googlemail.com> wrote:
> 2012/11/27 Joel Brobecker <brobecker@adacore.com>:
>> Hi Pavel,
>>
>>> Attached patch removes mingw from special cases of dlopen lookup. It
>>> allows dlopen to be found later in libdl and have it added properly as
>>> -ldl in bfd and sim builds.
>>>
>>> To reproduce the problem:
>>>
>>> ../configure --enable-plugins --target=arm-linux-android
>>> --host=i586-pc-mingw32msvc --build=i386-linux-gnu
>>> make
>>>
>>> Error:
>>> ../../bfd/libbfd.a(plugin.o): In function `try_load_plugin':
>>> /tmp/gdb/BUILD/bfd/../../bfd/plugin.c:170: undefined reference to `dlopen'
>>> /tmp/gdb/BUILD/bfd/../../bfd/plugin.c:177: undefined reference to `dlsym'
>>> /tmp/gdb/BUILD/bfd/../../bfd/plugin.c:173: undefined reference to `dlerror'
>>>
>>> ChangeLog:
>>>
>>> 2012-11-27 Pavel Chupin <pavel.v.chupin@intel.com>
>>>
>>> Fix libtool.m4 libdl lookup for mingw
>>> * libtool.m4: Remove mingw from special case of dlopen lookup
>>> * bfd/configure: Regenerate.
>>> * sim/arm/configure: Regenerate.
>>> * sim/avr/configure: Regenerate.
>>> * sim/bfin/configure: Regenerate.
>>> * sim/common/configure: Regenerate.
>>> * sim/cr16/configure: Regenerate.
>>> * sim/cris/configure: Regenerate.
>>> * sim/d10v/configure: Regenerate.
>>> * sim/erc32/configure: Regenerate.
>>> * sim/frv/configure: Regenerate.
>>> * sim/h8300/configure: Regenerate.
>>> * sim/iq2000/configure: Regenerate.
>>> * sim/lm32/configure: Regenerate.
>>> * sim/m32c/configure: Regenerate.
>>> * sim/m32r/configure: Regenerate.
>>> * sim/m68hc11/configure: Regenerate.
>>> * sim/mcore/configure: Regenerate.
>>> * sim/microblaze/configure: Regenerate.
>>> * sim/mips/configure: Regenerate.
>>> * sim/mn10300/configure: Regenerate.
>>> * sim/moxie/configure: Regenerate.
>>> * sim/rl78/configure: Regenerate.
>>> * sim/rx/configure: Regenerate.
>>> * sim/sh/configure: Regenerate.
>>> * sim/sh64/configure: Regenerate.
>>> * sim/v850/configure: Regenerate.
>>
>> Thanks for sending this patch.
>>
>> Changes to the root directory are controled by the GCC developers,
>> so you will need to send your patch there for approval. But looking
>> at your patch, I am wondering whether it is actually right. I have
>> two reasons for questioning your patch:
>>
>> - I don't think MinGW actually provides libdl, at least not by default.
>> Your change would probably break the build for those who do not
>> have the dlfcn extension installed;
>
> Right, by default there is no such library present. Therefore mingw
> can't dependent on the presence of such a library.
>
>> - Looking at bfd/plugin.c, there are implementations of these
>> dlfcn functions provided by that file for Windows.
>> These implementations are guarded by:
>>
>> #if !defined (HAVE_DLFCN_H) && defined (HAVE_WINDOWS_H)
>>
>> I am guessing that your MinGW install has dlfcn.h. Perhaps the problem
>> would need to be fixed in bfd instead (binutils AT sourceware dot org).
>
> Yes, I assume that a fix of the issue you had should be addressed in
> binutils instead.
>
> Regards,
> Kai
Thanks for review. You are right. I've removed mingw-dlfcn on my
machine and dlopen is picked up from plugin.c so issue is gone. It
seems to fix both cases need to add check for dlfcn.h for mingw and if
present use dlopen from libdl, otherwise use LoadLibrary version.
Looks like libtool.m4 is the right place to do such sort of checks.
What do you think?
--
Pavel Chupin
Intel Corporation
next prev parent reply other threads:[~2012-11-27 12:17 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-27 7:05 Pavel Chupin
2012-11-27 8:11 ` Joel Brobecker
2012-11-27 8:16 ` Kai Tietz
2012-11-27 12:17 ` Pavel Chupin [this message]
2012-11-27 13:33 ` Joel Brobecker
2012-11-27 14:58 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANwJu18Z_L9MuXy=3d3UTEucBjRmTH_93YwSebHgBm-hzuB=wg@mail.gmail.com' \
--to=pavel.v.chupin@gmail.com \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=ktietz70@googlemail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox