On 3/29/2013 1:54 AM, Ralf Corsepius wrote:
> On 03/29/2013 02:59 AM, Joel Brobecker wrote:
>> I was wondering if this discussion was stalled, or if it was just
>> a matter of not finding the time to do the implementation.
> Sorry, in my case, it's simply lack of time.
>
>> I could
>> possibly take care of it tomorrow if you'd like.  There is not real
>> rush, however, as I will be off next week, and thus unable to create
>> a release at least until Tue Apr 9th.
> I just did a test-rebuild with current gdb-7_6-branch (presuming Joel's
> new patches are in).
And Mike's.
> Using the same set of configuration options, I have been using for
> gdb-7.5.x, all targets build fine on Linux.
>
> However, there is a new breakdown for the m32r on mingw32-w64-{x86_64,i386}:
>
> ..../configure --build=i386-pc-linux-gnu \
> --host=x86_64-w64-mingw32 --target=m32r-rtems4.11
> --enable-sim [...] \
> ...
> checking how to recognize dependent libraries... configure: error:
> Sorry, but hardware support in this simulator unconditionally
> relies on dv-sockser.o which is unavailable for your host. Please fix
> this simulator.
> ...
>
> As gdb-7.5.x built fine with the same configuration, this to me
> qualifies as a regression - Or is this just a latent, so far silently
> accepted, but dysfunctional part being revealed by the new configuration
> magic?
Looking back at 7.5.91, I see that m32r unconditionally uses 
dv-sockser.o and
I don't know how it built before.

The references to dv-sockser.o methods appear to be properly conditionalized
in the code.  So it is the Makefile.in and our interpretation that the 
simulated
hardware should be "always on" versus "yes enabled" by default.

Attached is an untested patch.



> Ralf
>


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985