mingw-users Mailing List for MinGW - Minimalist GNU for Windows

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 20/08/17 21:16, David Gressett wrote:
> The offenders found so far are
> 
> gnatmake.exe -  crashes
> gnatlink.exe - can't find the files specified on its command line
> gnatclean.exe - crashes
> gnatxref.exe - does nothing, produces no error messages
> gnatls.exe - can't find the files specified on its command line
> gnatchop.exe - can't find the files specified on its command line
> 
> gnatbind.exe and gnatkr.exe seem to behave correctly.

Since Ada might just as well be greek (a language which I do not speak) 
to me ...

> At this point, new projects that were dumped on me have eaten up all
> of my round tuits. When I get back to this, I will open an issues
> ticket for this which will contain minimal source files which are
> used to cause the failures and also the exact error messages.

... until you can do this, there isn't much I can do to investigate.  
FWIW, under wine:

  $ WINEPATH=/mingw/bin dist/staged/bin/gnatmake.exe --version; rstty
  GNATMAKE 6.3.0
  Copyright (C) 1995-2016, Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.
  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A 
  PARTICULAR PURPOSE.

(and "gnatmake.exe --help", similarly, produces expected output).  
That's about the limit of the testing I can perform, unaided.  FTR, 
without "WINEPATH=/mingw/bin" it does crash, because libiconv-2.dll 
is nowhere that gnatmake.exe can find it, but I suspect that your 
issue is more fundamental than that.

I have rebuilt all of the packages, since uploading the distribution, 
to remove an accidental dependency on libmingwex-0.dll, but I don't 
believe any of the Ada tools were affected.  If it helps, I can make 
the rebuilt Ada binary package available, via your ticket, so you may 
check if the issue persists with that.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZmtL4AAoJEMCtNsY0flo/mBUP/i+W2WNA7ToKiHS+sFvOJqno
EKwmjnCqnF7/PkeY9vBebYLGBULOtmhB8ka+geVMW0Fpmu7FzIgv1gwmIvjwMNG3
WoHryvGozwyjfXlLz1uhF4xe3+tirZbVzKNNjhW7g7jB1GtXdGPOoKbBkxfFLgLm
8ymm3WTjpUMwRCxt36OsnMLuyt+uNP5I/PD0Q7PGebxcvRr7qmOHa3JRsXvpDYmN
gFHidnf9fhR+o6YHRKpIrfqIoNC2wKy5e7Ns9RRboQaVMyNdsFK+60IwPP4cxkDC
tZX0oUN8Rgw6rkcTJvpE/kQKXg9chV5DY8DuBY5Wn87eYzXgOz1GMeOD4Lcp7Vnx
lKFjWj4Q45xrqzQSt+srQmQScHE4iAjCiNbXMrS3xt2tFAUK7h/Ogy74OTvwWY0H
wX1E42PayGMU8uCZoZ46aw1kPHqHILPLvXx8uspA+HHmPFDMEOpP+Ye9CeDQpfqn
Dqq7b4khWtwrWBRGr3jWrlUdFAlqlDg3B+X2J3I/Yfp5TdXVMN6xknQsNQYGaWDC
aHp+0EY2A3IfFbupsyx0cZNbtsj4CDwk2Rr/NN+3HMak18xvb+KkSsWJafRYjCM0
lU42IDWcSYwqLp5RWXgX18LTJPhDczojaJzy1clRNePuq9hHyGqk5+5AbEIhIqBT
BOyU7WgcIsQnRFESRQU/
=PkrH
-----END PGP SIGNATURE-----

On Sunday, July 30, 2017  Keith Marshall wrote:

>On 27/07/17 16:22, David Gressett wrote:
>> Here is the source code of a simple program (test.adb) that fails to
>> build:
>> 
>> with Ada.Text_IO;
>> use Ada.Text_IO;
>> 
>> with Ada.Directories;
>> use Ada.Directories;
>> 
>> procedure Test
>> is
>>   Search: Search_Type;
>>   File: Directory_Entry_Type;
>>   
>> begin
>>   Start_Search(Search, ".", "*");
>>   
>>   while More_Entries(Search) loop
>>     Get_Next_Entry(Search, File);
>>     Ada.Text_IO.Put_Line(Simple_Name(File));
>>   end loop;
>>   
>>   End_Search(Search);
>>   
>> end Test;
>> 
>> When I try to build it, I get this:
>> 
>> $ gnatmake test
>> fatal error, run-time library not installed correctly cannot locate 
>> file system.ads
>> ǩ: *** make failed.

>FWIW, this WJFFM with the cross-compiler, with which I built GCC-6.3.0 as a MinGW.org distributable suite:

> $ mingw32-gnatmake test
>  mingw32-gcc -c test.adb
>  mingw32-gnatbind -x test.ali
>  mingw32-gnatlink test.ali

>Running it (under wine):

>  $ ./test.exe ; rstty
>  .
>  ..
>  test.o
>  test.adb
>  test.exe
>  test.ali

>(The "rstty" is there because wine lacks the courtesy to restore my terminal settings, after it has mucked about with them).

>> system.ads does exist; it is at
>> C:\MinGW\lib\gcc\mingw32\6.3.0\adainclude\system.ads

>In my case, it is in:

>  $ find ~/mingw32/ -name system.ads
>  /home/keith/mingw32/lib/gcc/mingw32/6.3.0/adainclude/system.ads

>(with the entire cross-compiler suite installed behind the ~/mingw32 symlink).

>> The problem occurs with two installations of GCC-6.3.0, one on a 
>> Windows 7 computer, and another on Windows 10.

>So, is this an issue with my crossed-native distribution build?  It clearly doesn't affect my cross-compiler itself.

I have located several points of failure. They are all distributed in

gcc-ada-6.3.0-1-mingw32-bin.tar.xz

They are in the bin subdirectory, which contains 13 executables. 
I have tested 8 of these at this point and 6 of the 8 do not work correctly as distributed.
When I overwrite them with my native-windows-built executables, the problems disappear.

The offenders found so far are

gnatmake.exe -  crashes
gnatlink.exe - can't find the files specified on its command line
gnatclean.exe - crashes
gnatxref.exe - does nothing, produces no error messages
gnatls.exe - can't find the files specified on its command line
gnatchop.exe - can't find the files specified on its command line

gnatbind.exe and gnatkr.exe seem to behave correctly.

At this point, new projects that were dumped on me have eaten up all of
my round tuits. When I get back to this, I will open an issues ticket for this
which will contain minimal source files which are used to cause the failures and
also the exact error messages.

Forwarding the bounced message from earlier today.

-------- Forwarded Message --------
Subject: Re: [Mingw-users] clock_gettime
Date: Mon, 14 Aug 2017 07:48:50 -0400
From: Earnie <ea...@us...>
To: min...@li...

On 8/13/2017 6:15 PM, Keith Marshall via MinGW-users wrote:
> On 13/08/17 21:04, Anton Shepelev wrote:
>> Thank you for the patch, Keith.  Do I understand aright from the
>> readme file that the simplest way to build the library is using
>> "use the special version of Jam made for Mingw32"?
> 
> I guess we should dump that readme.txt file; it is long obsolete.

Yes, as far as I remember the JAM files were only used with the original
set package files.  The JAM files have not been kept current and would
not even build the package without major overhaul.

-- 
Earnie

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13/08/17 21:04, Anton Shepelev wrote:
> Thank you for the patch, Keith.  Do I understand aright from the 
> readme file that the simplest way to build the library is using 
> "use the special version of Jam made for Mingw32"?

I guess we should dump that readme.txt file; it is long obsolete.  
See: https://sourceforge.net/p/mingw/mailman/message/35845151/, 
(and note my follow-up instruction about ensuring that you are on 
the right git branch).

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZkM+cAAoJEMCtNsY0flo/g0kQALLBeDM3WTb8c2a2MgwlCseM
QvpbUhAopWyZ9/wAdyzxk9I3oGc1yqYj6/wGQSh+MRXI8v2rvN1ZnX+gDDainzfE
DgDF89KCaCTEvSgT8LJ8zjDl7l4mk5HN+kE/yDU9OILbtzAdCO/xe/wegxVVetYJ
0TMsJ263yhPgSqmyz7TexD8dm+cauHO8862QDscVe8baLwgAzgk8hcWpcnIT4JP2
nUzZV7Yt8D1TK2be3GBjlAaLTtBfe794oe84nwLXsqV7rw4GH2CvuFvqh7XZOXOb
Bf9YPda09GJjI9yz2c8uBRDHapm8FPAZO+yNkWM+ejy5USTFqQ3wlk8zcgFE6vF8
TVFVqrnqNsI20GRMScJ3wAt/1oD4TN46QD4Dj5o9NfXDki3+K8OzA1Cap1IdCzvU
DKwjbIkMgaSf/VQSZi+kHKYyJbYLnUr6jIe4ir2NfaCeER/eujM9LXys2LkA/7XO
dk0SZXzMXhHNhJ+njqjJhkn6TmDlB0bm/PAUXANF2PJ/DVC49Tu8ivwkJzKFWCx/
E7jQTRHx/dokOJETmV6CxTSytlqFyBkjVpNHLAa84QzTcf+knQDhycoFqLAfE56P
7UuhT0n0Uks71kWXRjzuZcNsyha2pMFX9dCsWypmUmZpu+PD9G4Qci3gv4ivOXdY
5A+C2CX69igGwCuKZEmK
=CpXJ
-----END PGP SIGNATURE-----

Thank  you  for  the  patch, Keith.  Do I understand
aright from the readme file that the simplest way to
build  the library is using "use the special version
of Jam made for Mingw32"? Where can I take this ver-
sion  and  the corresponding jamfiles?  Although the
readme says that "tt should be  available  from  the
same place you got this file," it is absent from the
mingw-mingw-org-wsl source archive.  If the  sources
from  git do note come with a working build scripts,
is there some instructions on building them?

P.S.: I cannot reply to the relevant message because
      Gmane's  NNTP  server  is not showing new mes-
      sage.  If they do not fix it  soon  enough,  I
      shall switch to plain e-mail.
-- 
Please, do not forward replies to my e-mail.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 13/08/17 14:46, Anton Shepelev wrote:
> Keith Marshall to Marc Davenport:
>> Is there any chance of clock_gettime being implemented in MinGW?
>>
>> I think I've said this before; (if not, I've certainly alluded to
>> it): your best chance of getting such requests accepted is to file
>> them as "Feature Requests", at
>>
>>   https://sourceforge.net/p/mingw/bugs/new/ ,
>>
>> and then invite other users to vote for them, (by posting a
>> notification here).
> 
> Done:
> 
>   https://sourceforge.net/p/mingw/bugs/2349/
> 
> I couldn't register this issue as a feature request because when I
> selected "Feature Requests" in the "Ticket" drop-down list the
> "Create Ticked" button became locked, so I made it an "Issue".

You did it right.  The https://sourceforge.net/p/mingw/bugs/new/ link, 
which I gave you previously, takes you directly to the form which you 
should complete.  No need to invoke the "Tickets" drop-down, or the 
"Create Ticket" button ... just specify the ticket type as "Feature", 
as you complete the form, (which is what you did).

FTR, all but the "Issues" tracker, under the "Tickets" drop-down, are 
considered deprecated, and are provided only to access old tickets; a 
comment, at the top of each such tracker, instructs you to use the 
"Issues" tracker, for submission of new tickets.

- -- 
Regards,
Keith.

Public key available from keys.gnupg.net
Key fingerprint: C19E C018 1547 DE50 E1D4 8F53 C0AD 36C6 347E 5A3F
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQIcBAEBAgAGBQJZkG9hAAoJEMCtNsY0flo/5msP/R3NpMYHC0u9zc12fhpyEXck
xo3qJIQX7pHSttupsXm3o69CLTPIc0TBngxzdjTga4DnUNLLGL9IswYCsYk6/9rv
rzPLKDGE44YJcsmyNOqTrcyqIWuR2SZEurO38lTS8Ulx+P03agVIIznqgi5O3my2
3nBAGbgOqISPpndhCRZ5wSQ0CHnvpUtNisuS/QoYihpZLH90brBOZJ8pHa3kHw8y
9wfRIZTtILvVLyVZ4y0xIMjBPIecgbJEyOL6IKu0nz+6e2IoZmH7bk1uplGnwc7T
/cz8cCVQdt9RVADeKHzJdXOCJMWgm2NyGLOdY1vv2zQTZOs3lzwXqpaxW5b58hU9
XiP6DGQ4b9pK8HmFkO5ll+E4oZHnc7Owd5s33LgDOMUKeV6cDsbmAEhT6urEmKsM
9y8KB9VCHP2WZCRG4EMvjtmwV9ucSUFnIxKGnYApEPDrSoXFQXtcpXlfRkThTpMg
XWRJOQCCI5aGZcnTShm2/T1fMIYeZAFOkFYJkBT/uVSD8Pa8I4jaO8PH+s9abx4B
Sg1Sw4tZ9jEbUh08Q3KVi8QQlKt4xLGSJRWa6ek/k+22QGKZHufe6BZhZfecm6kh
il3vx+sQEO3YHq8MRr6OwcDd7bSOXzm4n0M9iKC/XLPSidstJf5ea/OCSVWOnSPO
CBwerZ8atbQmXF9rxrUo
=kv7S
-----END PGP SIGNATURE-----

Keith Marshall to Marc Davenport:

> Is  there any chance of clock_gettime being imple-
> mented in MinGW?
>
> I think I've said this before; (if not, I've  cer-
> tainly alluded to it): your best chance of getting
> such requests accepted is to file them as "Feature
> Requests", at
>
>   https://sourceforge.net/p/mingw/bugs/new/ ,
>
> and  then invite other users to vote for them, (by
> posting a notification here).

Done:

  https://sourceforge.net/p/mingw/bugs/2349/

I couldn't register this issue as a feature  request
because  when  I  selected "Feature Requests" in the
"Ticket" drop-down list the "Create  Ticked"  button
became locked, so I made it an "Issue".

-- 
Please, do not forward replies to my e-mail.

On 7/31/2017 11:27 PM, Greg Babcock wrote:
> I inherited an mingw 3.4.2 analytics application that has been in
> production for over 10 years that implements algorithms using
> dynamically linked DLLs.  I created 20 very simple new DLL’s that are
> essentially copy pastes of each other. 
> 
> ·        All DLL’s loaded properly with a test application that verifies
> the interface is correct
> 
> ·        Fourteen of the new DLLs load and work properly
> 
> ·        Three DLL’s fail to load all of the time with an “Invalid
> access to memory location” error
> 
> ·        Three DLLs fail to load (“Invalid access to memory location”)
> when a conflicting DLLs is loaded
> 
> ·        DllMain is just stubbed out, so it should not be causing any
> problems
> 
>  
> 
> The problem feels like a DLL is attempting to load at an address that
> another DLL has already been loaded, but this doesn’t make any sense
> because windows should handle that situation by relocating the DLL. 
> 
>  

Very possible the problem is as you suspect.

> 
> I would greatly appreciate any insight to what might be causing this
> issue, or suggested approaches or tools to use to debug the problem.
> 

Look into rebasing your DLL to load into a different memory space.
Sorry other than the Cygwin version (which may be able to be built
without Cygwin, don't know, haven't tried) I don't know of a link to
give you.

-- 
Earnie

I inherited an mingw 3.4.2 analytics application that has been in production
for over 10 years that implements algorithms using dynamically linked DLLs.
I created 20 very simple new DLL's that are essentially copy pastes of each
other.  

.        All DLL's loaded properly with a test application that verifies the
interface is correct

.        Fourteen of the new DLLs load and work properly

.        Three DLL's fail to load all of the time with an "Invalid access to
memory location" error

.        Three DLLs fail to load ("Invalid access to memory location") when
a conflicting DLLs is loaded

.        DllMain is just stubbed out, so it should not be causing any
problems

 

The problem feels like a DLL is attempting to load at an address that
another DLL has already been loaded, but this doesn't make any sense because
windows should handle that situation by relocating the DLL.  

 

I would greatly appreciate any insight to what might be causing this issue,
or suggested approaches or tools to use to debug the problem.

 

Thank You,

 

GB