Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro

[Greg Jung]

You should try "makepkg -g" and paste/copy the results, for the lines that
are different,  into the PKGBUILD.
Then, makepkg --check can be used to test it.

On Fri, Nov 23, 2018 at 10:51 AM Edward Diener <
eldlistmaili...@tropicsoft.com> wrote:

> On 11/23/2018 9:06 AM, Liu Hao wrote:
> > 在 2018/11/23 21:55, Edward Diener 写道:
> >> On 11/22/2018 9:07 PM, Liu Hao wrote:
> >> ==> Verifying source file signatures with gpg...
> >>  binutils-2.30.tar.bz2 ... FAILED (unknown public key
> 13FCEF89DD9E3C4F)
> >> ==> ERROR: One or more PGP signatures could not be verified!
> >>
> >> Do you have any idea of how I am supposed to fix the ERROR ?
> >>
> >
> > Passing `--skippgpcheck` to `makepkg-mingw` would likely overcome this
> > problem.
>
> I used --skippgpcheck' but am now getting this really cryptic error of:
>
> ==> Starting prepare()...
> patch: invalid argument 'E:\\Programming\\VersionControl' for
> '$VERSION_CONTROL'
> Valid arguments are:
>- 'none', 'off'
>- 'simple', 'never'
>- 'existing', 'nil'
>- 'numbered', 't'
> ==> ERROR: A failure occurred in prepare().
>  Aborting...
>
> I have an environment variable under Windows called VERSION_CONTROL but
> what that has to do with the problem above I do not understand. Does
> MSYS2 look for an environment variable called VERSION_CONTROL ?
>
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fixing bug in binutils for mingw-64 distro

[Greg Jung]

The recipe from Liu Hao is correct for what it describes and now the
nomenclature
needs to be discussed so that you can explain what you need.  You have
called something
"mingw-64" which is none of the options.
The MINGW group that MSYS2 uses employs the preamble, "mingw-w64" for the
native software
 (i.e.. gcc.) so  the 32-bit versions are called "mingw-w64-i686- and
the 64-bit versions
are called "mingw-w64-x86_64-".  MSYS2 is a posix system, a subset of
CYGWIN.
In MSYS2, the directory tree /mingw64 holds native programs produced by/for
mingw-w64-x86_64,
and /mingw32 does the same, for the i686 mode.  The name, "mingw32" is also
used as a generic identifier
(as for the make program, "mingw32-make" found in both /mingw64/bin and in
/mingw32/bin)

For binutils, you may have up to three versions of them. I do:

$ pacman -Ss binutils
mingw32/mingw-w64-i686-binutils 2.29.1-1 (mingw-w64-i686-toolchain)
[installed: 2.25.1-1]
A set of programs to assemble and manipulate binary and object files
(mingw-w64)
mingw64/mingw-w64-x86_64-binutils 2.29.1-1 (mingw-w64-x86_64-toolchain)
[installed: 2.25.1-1]
A set of programs to assemble and manipulate binary and object files
(mingw-w64)
msys/binutils 2.28-1 (msys2-devel) [installed: 2.25-2]
A set of programs to assemble and manipulate binary and object files

On Thu, Nov 22, 2018 at 6:49 PM Edward Diener <
eldlistmaili...@tropicsoft.com> wrote:

> On 11/22/2018 9:07 PM, Liu Hao wrote:
> > 在 2018/11/23 上午7:50, Edward Diener 写道:
> >> There is a bug which in binutils which causes clang targeting
> >> mingw-64/gcc on Windows to create a bad windows executable. The bug is
>
> >>
> >
> > If you already have MSYS2 then upgrading its packages is easy:
>
> I do not believe I am trying to upgrade an MSYS2 package. Rather I am
> trying to fix a mingw-64/gcc-8.1 installation in Windows itself so that
> the binutils part of the installation can be replaced by the fixed
> component(s). In particular I am trying to upgrade the ld.exe in the
> installation so that it performs the link correctly even for clang. I
> don't mind creating another completely separate mingw-64/gcc-8.1
> installation under MSYS2 which works natively under Windows if
> necessary, as long as it contains the fix. Does this make any difference
> in your instructions ? Also when doing things within MSYS2 am I opening
> the MSYS2 MSYS prompt or am I opening the MSYS2 MingW 32-bit or MSYS2
> MingW 64-bit prompts ? I am on a 64-bit machine. From what I understand
> about MSYS2 the MingW 32-bit and MingW 64-bit prompts allow me to create
> native Windows applications, but I do not understand the difference
> between using either of the two.
>
> >
> > 1. Clone 'https://github.com/Alexpux/MINGW-packages.git'.
> > 2. CD into 'mingw-w64-binutils', where there are a series of patches and
> > a file named 'PKGBUILD'.
> > 3. Save the commit in question as a patch file.
> > 4. Add that patch into 'PKGBUILD'. Note that there are two places where
> > it is expected. The checksum need not be updated.
> > 5. Run `updpkgsums` in an MSYS2 shell to update the checksum for the new
> > patch.
> > 6. Run `makepkg-mingw` in an MSYS2 shell. This builds both mingw32 and
> > mingw64 packages for you.
> > 7. Wait for the build process to finish. There should be sort of
> > 'mingw-w64-{i686,x86_64}-binutils*.tar.xz' in the current directory
> > after the packages are built successfully.
> > 8. Run `pacman -U ' to install these packages. Remember to
> > replace  with the real names of your packages. Wildcards
> > are allowed.
> >
> >
> >
> >
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >
>
>
>
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] cannot get functions in fileapi.h (gcc 5.3)

[Greg Jung]

Hi all,
  I am trying to read a link target. Its already established with a handle
and
deemed to be a link, and so the next step is to call
GetFinalPathNameByHandleW
In Window 7 using gcc 5.3:
#undef _WIN32_WINNT
#define _WIN32_WINNT 0x0601
#include 
 ...
#if _WIN32_WINNT >= 0x0600
DWORD dwresult;
dwresult = GetFinalPathNameByHandleW(
  hFind,  FilePath,  MAX_PATH+1,
  dwFlags);
 #endif

which generates the error,
F:/gdl/src/file.cpp:312:26: error: 'GetFinalPathNameByHandleW' was not
declared in this scope
   dwFlags);

Any clues out there about what's missing? Thx.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Regarding gcc and libwinusb for win64

[Greg Jung]

Pre-built gcc versions are to be found here:
https://sourceforge.net/projects/mingw-w64/files/mingw-w64/

On Mon, Aug 20, 2018 at 5:31 AM Aditya .  wrote:

> Hello,
>
> Hope you are doing well.
>
> Myself Aditya working on usb HCI drivers on windows 64bit machine.
>
> We use some of the APIs provided by windows Usb core(libwinusb) to
> communicate to usb hardware. As I came to know mingw-w4 provides gcc for
> windows and corresponding libraries also.
>
> I downloaded mingw-w64-v5.0.4.zip file and trying to compile the same.
>
> When I do ./configure in mingw-w64-v5.0.4 directory IAM getting errors like
> can't build mingw-w64-crt.
>
> I basically need gcc tool chain and corresponding libraries like libwinusb
> etc.
>
> Please support on how to install the gcc and build libraries like libwinusb
> in windows 64 bit machine. I tried following how to build docs. But still I
> couldn't able to move forward.
>
> Waiting for your reply.
>
> Regards,
> Aditya
>
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] problem compiling QT: where to report?

[Greg Jung]

On Thu, Mar 24, 2016 at 3:03 AM, Mario Emmenlauer 
wrote:

>
> Hi Ruben,
>
> thanks for this very very good pointer!! I did not dare look behind
> the scenes of the MinnGW packages, but it turns out that was my
> mistake, they are indeed readable, and helpful! :-)
>
> One more question, if I may: in the PKGBUILD you pointed out, there
> seems to be a "wild" :-) mix of recommended packages from mingw and msys.
> Is there an easy beginners guideline which package to prefer if both
> exist, something like: always prefer mingw-package over msys-package?
> Should I use python2 from msys or mingw? Or install both? For another
> build, I tried cmake from msys and miserably failed, whereas cmake from
> mingw worked out of the box. Is mingw usually "preferable"?
>
> Thanks for your help, and all the best,
>
> Mario
>
>
Mario,
   based on your question you seem to be fuzzy on a basic fact, that is,
the "msys" packages
are a separate platform from those with the mingw-w64 designations.  msys
is there
principally to support the shell and build system.  Often enough, a
configure scheme will use
python as a utility and so yes python and perl, from /usr/bin tree, will be
useful.

  The mingw platforms does not include the posix compatibility layer of
msys.

  So mingw programs and constituent libraries are kept separate from those
in support of msys.
the /mingw64 directory tree etc.  So the msys package "cmake" is overall
completely incompatible with
what you are doing - and it is built with "MSYS Makefiles" generator
removed to help clue you into that fact.
When you install /mingw64/cmake you will have much better results: cmake
will awake in the environment
it  was meant to build from.
  You should probably un-install the msys cmake, gcc, fortran versions that
would get you into trouble.
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785351&iu=/4140___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] using mingw-64 in Cygwin - "how to"

[Greg Jung]

 You shouldn't have t make any part of the toolchain, they are there to be
installed from cygwin setup.  The names go like "mingw64-x86_64-gcc-g++"
etc. (no mingw32 mentioned).

For usage instructions, there should be something on cygwin.org.  It might
be as simple
as inserting /usr/x86_64-w64-mingw32/bin at the head of your path.

On Tue, Aug 18, 2015 at 12:32 AM, foehn  wrote:

> Hi there,
>
> I installed x86_64-w64-mingw32-gcc collections from Cygwin setup and want
> to know what to do
> next to make the "x86_64-w64-mingw32-*" tools (x86_64-w64-mingw32-gcc,
> x86_64-w64-mingw32-g++,
> x86_64-w64-mingw32-ar, ...) function as being called like "gcc, g++,
> ar...". The link
> (http://mingw-w64.org/doku.php/download/cross-compilation) is broken in
> the document page
> (http://mingw-w64.org/doku.php/download/cygwin). By link or alias or some
> procedure else?
> Thanks in advance.
>
> Foehn
>
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] wchar_t vs char

[Greg Jung]

In my programming instead of  "multibytetowide" conversion preparing for a
windows API inside  #ifdef UNICODE blocks, I just call the ANSI mode of the
function with ascii c-strings
passed in, and let microsoft perform the A->W conversions.  When does this
simpler approach break?

   - Only use Win32 functions that accept widechars (LPWSTR), never those
   which accept LPTSTR or LPSTR. Pass parameters this way:

   ::SetWindowTextW(widen(someStdString or "string litteral").c_str())

   (The policy uses conversion functions described below.)


On Tue, Jun 30, 2015 at 10:36 AM, Alexandre Pereira Nunes <
alexandre.nu...@gmail.com> wrote:

> Grasp this sentence: implementation dependent.
>
> wchar_t is wide char, it's made to imply that each representable character
> can take more than one byte to encode a character. It was created before
> utf8 got mainstream. And, as there were competing encodings (UCS-2 fixed
> length vs what ended up being UTF-16 with variable length encoding), the
> standardization committees didn't pick one.
>
> While UTF8 is compatible with C encoding of strings (null termination), it
> uses variable length encoding (so strlen(buffer) doesn't work for utf8 as
> it would for asc-ii, because it counts bytes, not characters).  It's
> otherwise a superset of ASC-II like most "national" encodings microsoft
> uses for their routines ending in "A" (as opposed to "W", for "Wide").
>
> Only UTF32 has fixed length encoding (I overheard people saying it's not
> exactly true even there, because it has unrepresentable code points, but I
> never confirmed).
>
> Microsoft started using a fixed length 2-byte encoding  (UCS-2 IIRC) which
> was a more or less subset of utf16, but it swapped it (with bugs being
> slowly fixed over the years) by utf16 because by the time utf16 was
> standardized, people had already realized that 16 bits doesn't cover every
> symbol in every language, thus utf16 can take more than one 16-bit sequence
> code to represent a visible character (a symbol).
>
> It was natural for Microsoft to standardize MSVC's wchar_t to 16bit since
> it supported it natively in it's revamped UCS2 (now UTF-16) API, but many
> other platforms have wchar_t as UTF32.
>
> Nowadays you have standardized converters between each of these encodings
> even in the C++ library, but as conversion is expensive (and so is storage,
> so sometimes you have to convert, depending on the data, i.e. long english
> pure text use the same amount of data in utf8 than it would use in plain
> ascii, and in fact, it would be the same: utf8 is an ASCII superset).
>
> I feel the pain, trust me: I have a program written in C++ that interfaces
> with windows (via 16-bit ucs-16), a huge third-party code base using
> UTF-32, and gtk (which uses utf8 for everything). If it wasn't so easy
> (well, it isn't, but you get it over time) to use type safety in C++, I
> would be passing the wrong string type around more times than I could
> count. I ended up using a pre-C++11 converter to adapt the strings on
> demand, but today it would be easier.
>
> Btw, I always swim against the mainstrean and when programming windows, I
> normally follow these advices (among others):
>
> http://utf8everywhere.org/
>
> But I *can't* and I *won't* suggest you or anyone else do the same
> blindly; There are reasons pro and against these tips; For me it was a win,
> but I can see why some people/organizations would pay a price which is too
> high for a not worthy return.
>
>
>
> Em ter, 30 de jun de 2015 às 14:04, LRN  escreveu:
>
>> On 30.06.2015 19:44, p...@arbolone.ca wrote:
>> > I have been reading that wchat_t, and therefore wstring, is neither
>> UTF-8 nor a UTF-16 character set. So, what is wstring good for then?
>> Whether it's UTF-16 or UCS-2 depends on the implementation of the library
>> that handles wstring.
>>
>> Sources, which i can't remember right now, claim that MS libraries were
>> UCS-2 initially, then later quietly converted to UTF-16 under the hood.
>>
>>
>> --
>> O< ascii ribbon - stop html email! - www.asciiribbon.org
>>
>> --
>> Don't Limit Your Business. Reach for the Cloud.
>> GigeNET's Cloud Solutions provide you with the tools and support that
>> you need to offload your IT needs and focus on growing your business.
>> Configured For All Businesses. Start Your Cloud Today.
>> https://www.gigenetcloud.com/
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
>
> --
> Don't Limit Your Business. Reach for the Cloud.
> GigeNET's Cloud Solutions provide you with the tools and support that
> you need to offload your IT needs and focus on growing your business.
> Configured For All Businesses. Start Your Cloud Today.
> https://www.gigenetcloud

[Mingw-w64-public] Fwd: Where has the time gone?

[Greg Jung]

So I repeat the query, up the chain,

-- Forwarded message --
From: Alexey Pavlov 
Date: Fri, Apr 3, 2015 at 12:20 AM
Subject: Re: [Msys2-users] Where has the time gone?
To: Greg Jung 
Cc: "msys2-us...@lists.sourceforge.net" 



> 3 апр. 2015 г., в 10:12, Greg Jung  написал(а):
>
> I notice in  gcc version 4.9.2 (Rev2, Built by MSYS2 project), that I
> am missing the declarations found in time.h
> functions (strftime, gmtime, time()) where previously, gcc version
> 4.8.2 (i686-win32-sjlj, Built by MinGW-W64 project)
> with the aggregate of .h, .hpp etc. inclusions, there was no such
> requirement.  Since the files are shared
> with people who also have no need for time.h, (and usually earlier gcc
> versions) I'd like to know, is this a bug or a feature?
> I can't clone the CVS and compile (with msys2) without patching each
> of about 8 files to include .
> Is this the path of the future or an unfortunate mishap.
>
The is changed upstream in mingw-w64 runtime. Nothing with MSYS2 itself.

Regards,
Alexey.

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] static libgcc in multiple shared libraries

[Greg Jung]

My 2c, which is not authoritative but perhaps can throw a few more
topics into the mix.
First remember this: there are compiler-specific versions of
libstdc++, incompatible but nevertheless named the same,  dependent
upon the exception method deployed by the compiler.
AFAIK the only way to force a user to find only the (shared lib)
version of libstdc++ you designate is to include this where the .exe
resides and to run the program from that directory (since you can't
count on the path being set).

If a program is linked with static libgcc, again AFAIK, libgcc is a
dead end and doesn't need more support except what is commonly
available, i.e. in windows/system32/...  So a library built in the
same manner
will be using its own copies of libgcc routines and all of the names
have been stripped, so there would be no clashes.  If one of the libs
used shared libgcc thats ok too, and libstd++ will use that instead of
loading its own.


On Tue, Mar 31, 2015 at 7:02 AM, Cosmin Apreutesei
 wrote:
> Hi,
>
> I'm looking for the best way to distribute binaries for a main exe and
> several C and C++ plugins separately and I have a few questions about
> linking libgcc and libstdc++.
>
> Currently, the main exe (a C program) is linked with static-libgcc.
> Several C libraries that are loaded via LoadLibrary() are linked with
> static-libgcc too.
>
> Is this setup supported? I.e. does libgcc have initialization or
> shared globals that require it to be always linked dynamically or am I
> ok to link it statically into multiple shared libraries like that?
>
> What happens if I also load a C++ library next? A C++ library will
> pull in libstdc++ which will pull in a shared libgcc. Am I still on
> solid ground here? Basically now I have libgcc statically linked into
> the main exe _and_ dynamically linked from libstdc++.
>
> Good or no good?
>
> Thank you,
> Cosmin.
>
> --
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [ANN] Website changes

[Greg Jung]

I'm only recently felt that I know enough to propose the following as
an opening statement, which I hope is politik:

" Mingw-w64 is an advancement of the original Mingw system (mingw.org)
created to support the GCC compiler on windows-based systems.
Programs compiled with Mingw rely on the mingw runtime library to
bridge semantic differences between posix functionality and the
proprietary windows system calls.
Mingw additionally provides header files that facilitate direct access
to most useful windows system procedures.
The Mingw-w64 project started as an effort to extend the Mingw system
to also provide 64-bit support; technical disputes prevented this
initial effort from melding with the mingw.org code base, so that
Mingw-w64 is a fork since (Mingw.org) version V.xx.  Thus, Mingw-w64
version numbering begins at 2.0; its most recent version is 4.0.1.

Mingw-w64 brings free software toolchains to Windows. It hosts a
vibrant community which builds and debugs software for Windows while
providing development environment for everyone to use.
"


On Tue, Mar 24, 2015 at 1:20 PM, Adrien Nader  wrote:
> Hi,
>
> On Tue, Mar 24, 2015, David Macek wrote:
>> On 20. 3. 2015 22:51, Adrien Nader wrote:
>> > Hi,
>> >
>> > I've just pushed a redirect from http://mingw-w64.sourceforge.net to
>> > http://mingw-w64.yaxm.org in order to serve a new website.
>> >
>> > [snip]
>> >
>> > Any constructive criticism is welcome; don't hesitate.
>>
>> Hi. I took a look on the website and I've got some notes which may or may 
>> not be applicable to other visitors:
>>
>> === Downloads/Others:
>>
>> The first paragraph in the tab talks about OS X builds straight away, as if 
>> Others == OSX. This also led to an impression that Rubenv's builds are also 
>> for OS X. Also most of the contents of the tab seems to belong to other 
>> tabs. I imagine that if a visitor was interested only in toolchains for 
>> Windows, he/she could be led to believe that the three options in the first 
>> tab were the only one, because he/she would never even look at the Others 
>> tab and discovered the link to SF.net file repository.
>>
>> The following organisation would make more sense to me: I propose 1) moving 
>> Rubenv's builds to the Windows tab, moving the mention of OpenSUSE to the 
>> Linux tab, 3) copying the link to SF.net to all relevant tabs (or completely 
>> outside of them), and 4) renaming the tab from Other to OS X. I don't think 
>> moving these mentions from the Others tab to the other tabs will confuse 
>> users as to which one to download, as the gray boxes with logos serve well 
>> to make their contents seem as more trust-worthy than the plain text around.
>
> The "Others" tab has not received much love and that dates back to the
> creation of the download page on the previous website.
> When I put rubenvb and opensuse toolchains back when I created the
> download page (it's been some time already), the reactions I had
> received from both upstreams were at best "meh" and without many more
> details so I couldn't do a lot. I really wanted to put them somewhere
> though (I think Opensuse's effort started at least 7 years ago and
> rubenvb toolchains were widespread). Ideally they'd be in a proper
> place: the "others" section would ideally only contain the link to
> Sourceforge's FRS. That requires the corresponding toolchain creator to
> provide information about their releases.
>
> Following Vincent Torri's mail, I did some changes this morning and I
> just noticed I had not done these changes for every block but only for
> the ones that fell under Windows and Linux tabs. I've now corrected it.
> Basically I've removed title elements and added blue-colored blocks
> instead. They should make it easier to tell each block apart. Can you
> check the page again and tell me if it looks better?
>
> Also, the OS X situation currently is not very good as there is
> toolchain provider and the toolchains that are available are old,
> experimental and unsupported. I'm not worrying about it at the moment
> since it should change soon (more on that later on).
>
>> === Downloads/Source:
>>
>> This may be just my profession talking, but links to various stuff on SF.net 
>> with "SourceForge" as the title seem misleading.
>>
>> === Downloads/Linux:
>>
>> I know Arch Linux users are generally competent, but I'd like to see the 
>> link point to something actually related to mingw-w64, rather than just to 
>> AUR homepage. This may be a good link: 
>> 
>
> I'm not an Arch Linux user and the link in place was the only one I had.
> I've updated the page, thanks.
>
>> Also, wouldn't it be better to also mention the packages in official Arch 
>> repos?  They don't seem 
>> outdated or anything.
>
> I wasn't aware of these packages (maybe they're newer than the
> arch-linux-related update). I'm not sure how they relate to AUR ones;
> I'm

Re: [Mingw-w64-public] How to recognize symlinks in WIN32?

[Greg Jung]

Thanks all, let me summarize the situation:

   cygwin has its own trick to make a symlnk where the native OS doesn't
cooperate, which is a simple file beginning with the char[11]='!'
then 0xFF,0xFE, then wide-char name of where the link points.
In windows a symlink creator needs elevated privilege and so native
symlinks may not be sufficient.

   cygwin lstat is trained to recognize this.  The first clue is that it is
a system file - if the system attribute is erased, cygwin looks at a simple
file.
(It doesn't care that it is marked hidden or not). Then symlinks would have
'!',0xff,0xfe as first 12 bytes;

incorporating winsymlinks:native invokes the cygwin "ln" command to
create native symlinks if the shell is run as administrator, cywin links if
not.
winsymlinks:nativestrict would break non-native symlink creation.

That's all very useful thanks for the help.

On Thu, Jan 15, 2015 at 12:23 AM, David Macek 
wrote:

> On 15. 1. 2015 4:11, Greg Jung wrote:
> > Yes I've seen that, if my second post appeared, the symlinks created
> with cygwin are the ones giving me trouble.  These links are invisible to
> CMD.exe, by someone's
> > design:
> >
> > CYGWIN- created links in
> >  Directory of e:\cygwin64\lib\nox
> >
> > 03/31/2014  09:39 AM  .
> > 03/31/2014  09:39 AM  ..
> > 07/01/2013  03:24 AM   336,710 libXpm-noX.a
> > 07/01/2013  03:24 AM43,690 libXpm-noX.dll.a
> >2 File(s)380,400 bytes
> >2 Dir(s)  85,657,726,976 bytes free
>
> I think these are cygwin emulated symlinks:
>
> They are visible, just not by default. I suspect they are marked with the
> system attribute. Use "dir /as" to show them. You should see a small size
> (in order of tens of bytes).
>
> You can instruct cygwin to create native NTFS symlinks, but due to a
> different design, there are some restrictions. See this: <
> https://cygwin.com/cygwin-ug-net/using.html#pathnames-symlinks>
>
> > So the question becomes, "why do cygwin symlinks look different, and how
> can a user program detect this attribute?
>
> I assume you could detect them using cygwin *stat calls. Maybe by
> compiling against cygwin headers and cygwin1.dll, or maybe by extracting
> the relevant code from cygwin sources (you'd have to check the relevant
> licenses).
>
> --
> David Macek
>
>
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] How to recognize symlinks in WIN32?

[Greg Jung]

Yes I've seen that, if my second post appeared, the symlinks created with
cygwin are the ones giving me trouble.  These links are invisible to
CMD.exe, by someone's
design:

CYGWIN- created links in
 Directory of e:\cygwin64\lib\nox

03/31/2014  09:39 AM  .
03/31/2014  09:39 AM  ..
07/01/2013  03:24 AM   336,710 libXpm-noX.a
07/01/2013  03:24 AM43,690 libXpm-noX.dll.a
   2 File(s)380,400 bytes
   2 Dir(s)  85,657,726,976 bytes free

from mingw.org/msys bash:
greg@Homerw7 /f/git/bldgdl
$ ls -la /e/cygwin64/lib/nox
total 634
drwxr-xr-x  2 greg Administrators   4096 Mar 31  2014 .
drwxr-xr-x 77 greg Administrators 262144 Sep 25 21:36 ..
-rw-r--r--  1 greg Administrators 336710 Jul  1  2013 libXpm-noX.a
-rw-r--r--  1 greg Administrators  43690 Jul  1  2013 libXpm-noX.dll.a
-rw-r--r--  1 greg Administrators 38 Mar 29  2014 libXpm.a
-rw-r--r--  1 greg Administrators 46 Mar 29  2014 libXpm.dll.a

from cygwin/bash:
$ ls -la /e/cygwin64/lib/nox
total 638
drwxrwxrwx+ 1 greg None  0 Mar 31  2014 .
drwxrwxrwx+ 1 greg None  0 Sep 25 21:36 ..
lrwxrwxrwx  1 greg None 12 Mar 29  2014 libXpm.a -> libXpm-noX.a
lrwxrwxrwx  1 greg None 16 Mar 29  2014 libXpm.dll.a -> libXpm-noX.dll.a
-rwxrwxrwx+ 1 greg None 336710 Jul  1  2013 libXpm-noX.a
-rwxrwxrwx+ 1 greg None  43690 Jul  1  2013 libXpm-noX.dll.a

  And the same result from msys2 bash.
The CMD.exe directory command of a native symlink looks like so:
 Directory of c:\msys64\opt

01/14/2015  03:02 PM  .
01/14/2015  03:02 PM  ..
12/08/2014  09:40 PM  bin
11/08/2014  02:47 PM  doc
11/06/2014  01:29 AM  etc
11/17/2014  06:22 PM  include
11/04/2014  01:09 AM  info
12/08/2014  04:37 PM  lib
12/08/2014  09:39 PM  lib64
05/24/2014  09:11 AM  man
11/18/2014  04:23 PM  pkgconfig
11/05/2014  09:16 PM  share
11/04/2014  01:09 AM  var
01/14/2015  03:02 PM  ww [yypkg.exe]
11/08/2014  08:57 AM  x86_64-w64-mingw32
01/14/2015  02:36 PM  yy [yypkg.exe]
11/04/2014  01:04 AM 2,348,046 yypkg.exe
   3 File(s)  2,348,046 bytes
  14 Dir(s)  40,575,012,864 bytes free
on cygwin the native links ww,yy look just like cygwin symlinks:
 $ls -la
total 2576
drwxrwxrwx+ 1 greg   None   0 Jan 14 15:02 .
drwxrwxrwx+ 1 greg   None   0 Nov 17 18:21 ..
drwxrwxrwx+ 1 greg   None   0 Dec  8 21:40 bin
drwxrwxrwx+ 1 greg   None   0 Nov  8 14:47 doc
drwxrwxrwx+ 1 greg   None   0 Nov  6 01:29 etc
drwxrwxrwx+ 1 greg   None   0 Nov 17 18:22 include
drwxrwxrwx+ 1 greg   None   0 Nov  4 01:09 info
drwxrwxrwx+ 1 greg   None   0 Dec  8 16:37 lib
drwxrwxrwx+ 1 greg   None   0 Dec  8 21:39 lib64
drwxrwxrwx+ 1 greg   None   0 May 24  2014 man
drwxrwxrwx+ 1 greg   None   0 Nov 18 16:23 pkgconfig
drwxrwxrwx+ 1 greg   None   0 Nov  5 21:16 share
drwxrwxrwx+ 1 greg   None   0 Nov  4 01:09 var
lrwxrwxrwx  1 Administrators None   9 Jan 14 15:02 ww -> yypkg.exe
drwxrwxrwx+ 1 greg   None   0 Nov  8 08:57 x86_64-w64-mingw32
lrwxrwxrwx  1 Administrators None   9 Jan 14 14:36 yy -> yypkg.exe
-rwxrwxrwx+ 1 greg   None 2348046 Nov  4 01:04 yypkg.exe


On Wed, Jan 14, 2015 at 6:16 PM, dw  wrote:

>  I'm not quite sure what you are looking for.  However, maybe this will
> help:
>
> Data.raw does not have the FILE_ATTRIBUTE_REPARSE_POINT attribute set.
> Similarly, ffd.dwReserved0 is 0.
> Data2.raw DOES have the FILE_ATTRIBUTE_REPARSE_POINT attribute.  And
> ffd.dwReserved0 shows IO_REPARSE_TAG_SYMLINK.
>
> FWIW.
>
> dw
>

For some reason my second post was bounced (maybe it didn't like a link I
referenced)

The links I couldn't detect earlier were created by cygwin install
> procedure, i.e. cygwin64/lib/noX has two files and
> two symlinks pointing to the files: fstat_win32 below didn't find a
> FILE_ATTRIBUTE_REPARSE_POINT in its mask.
>
> Nevertheless, cygwin and msys2 "ls -la" commands show a symlink.  They
> work like a symlink should.
> So the question becomes, "why do cygwin symlinks look different, and how
> can a user program detect this attribute?
>
> On 1/14/2015 9:33 AM, Greg Jung wrote:
>
> Hi Folks,
>   I've been trying to program a recognition of NTFS symbolic link files;
>  What I;ve gleaned
> from MSDN procedures don't seem to work.  Below are coded three methods
>
>  1) (untested) open file and call GetFileInformationByHandleEx.  I can't
> get winbase.h header definitions recognized
>  2) GetFileAttributes() works ok for Junctions doesn't recognize symlink
> 

Re: [Mingw-w64-public] How to recognize symlinks in WIN32?

[Greg Jung]

Hi all,
  I've been doing some experimentation today and discovered another twist
in the story
which relates to cygwin - so I forward this on to cygwin-user list, also.
  I have been testing the code below against symlinks created
in cygwin64 (I'm running win7 64-bit; I have mingw/msys, msys2 (64), and
cygwin64 installations).
My code hadn't detected symlink files but all of thesymlinks I was trying
were cygwin64.
I created some symlinks natively, using an ln.exe (from
http://schinagl.priv.at/nt/hardlinkshellext/hardlinkshellext.html)
and using mklink.exe; these links *-do show up-* as reparse points in my
detection scheme 3), (but 2) should also work)  described below.
 The links I couldn't detect earlier were created by cygwin install
procedure, i.e. cygwin64/lib/noX has two files and
two symlinks pointing to the files: fstat_win32 below didn't find a
FILE_ATTRIBUTE_REPARSE_POINT in its mask.

Nevertheless, cygwin and msys2 "ls -la" commands show a symlink.  They work
like a symlink should.
So the question becomes, "why do cygwin symlinks look different, and how
can a user program detect this attribute?

(I've edited the original message to correct the lstat call )

On Wed, Jan 14, 2015 at 9:33 AM, Greg Jung  wrote:

> Hi Folks,
>   I've been trying to program a recognition of NTFS symbolic link files;
>  What I;ve gleaned
> from MSDN procedures don't seem to work.  Below are coded three methods
>
> 1) (untested) open file and call GetFileInformationByHandleEx.  I can't
> get winbase.h header definitions recognized
>  2) GetFileAttributes() works ok for Junctions doesn't recognize symlink
> files
>  3) FindFirstEx . same result as 2)
>
> There must be a way, since cygwin 'ls -a' and msys2 'ls -a'  commands will
> show links.
>
>  in the calling routine, I modify result of stat() (from glibc, I take it)
> from with system calls:
> #ifdef _WIN32
> int addlink = 0;
> fstat_win32(filename.c_str(), addlink);
> int actStat = stat(filename.c_str(), &statStruct);
> if( addlink != 0) cout << " addlink came back " << endl;
> statStruct.st_mode |= addlink;
> #else
> int actStat = lstat( filename.c_str(), &statStruct);
> #endif
>
> where fstat_win32 now has a graveyard full of attempts: ( When a directory
> link is encountered, however, the test succeeeds.)
>
>   void fstat_win32(const string& filepath, int& st_mode)
> {
> DWORD dwattrib, reparsetag;
> DString st;
> st=filepath;
> #if 1
> //
> //  This method has not been tested: it will not compile -
> GetFileInformationByHandleEx
> //  does not get through from the winbase.h header
> //
> HANDLE hFile;
> BOOL success;
> DWORD fattrib[2];
> hFile = CreateFile( (TCHAR *)st.c_str(),
> FILE_GENERIC_READ,
> FILE_SHARE_READ | FILE_SHARE_WRITE,
> 0,
> OPEN_EXISTING,
> FILE_FLAG_OPEN_REPARSE_POINT,
>   0);
> if (hFile == INVALID_HANDLE_VALUE) {
> CloseHandle(hFile);
> cout << " stat_win32: could not open " + st << endl;
> return;
>}
> else {
> success = GetFileInformationByHandleEx( hFile,
> FileAttributeTagInfo,
> &fattrib,
> sizeof(fattrib));
> dwattrib = fattrib[0];
> reparsetag = fattrib[1];
> }
> CloseHandle(hFile);
>
> //dwattrib = GetFileAttributes( (TCHAR *)st.c_str()); // This doesn't
> work to find symlinks
> if( (dwattrib & FILE_ATTRIBUTE_REPARSE_POINT) != 0 )  {
> st_mode |= S_IFLNK;
> cout << " fstat_win32: symbolic link detected and flagged!! " <<
> filepath ;
> }
>  else st_mode=0;
> #elif 0
> DWORD dwlen;
> HANDLE hFind;
> BOOL foundnext;
> WIN32_FIND_DATA FindFileData;
> // This doesn't work to find symlinks
> hFind = FindFirstFileEx( (TCHAR *) st.c_str(),
>  FindExInfoStandard,
>  &FindFileData,
>  FindExSearchNameMatch, NULL, 0);
> if (hFind == INVALID_HANDLE_VALUE)
> return;
> dwattrib = FindFileData.dwFileAttributes;
> if( (dwattrib & FILE_ATTRIBUTE_REPARSE_POINT) != 0 )  {
> st_mode |= S_IFLNK;
> cout << " fstat_win32: symbolic link detected and flagged!! " <<
> filepath ;
> dwattrib = FindFileData.dwReserved0;
> // IO_REPARSE_TAG_SYMLINK _MOUNT_POINT etc.
> }
>FindClose(hFind);
> #endif
> return;
> }
>
>
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] How to recognize symlinks in WIN32?

[Greg Jung]

Hi Folks,
  I've been trying to program a recognition of NTFS symbolic link files;
 What I;ve gleaned
from MSDN procedures don't seem to work.  Below are coded three methods

1) (untested) open file and call GetFileInformationByHandleEx.  I can't get
winbase.h header definitions recognized
 2) GetFileAttributes() works ok for Junctions doesn't recognize symlink
files
 3) FindFirstEx . same result as 2)

There must be a way, since cygwin 'ls -a' and msys2 'ls -a'  commands will
show links.

 in the calling routine, I modify result of stat() with system calls:
#ifdef _WIN32
int addlink = 0;
fstat_win32(filename.c_str(), addlink);
int actStat = stat(filename.c_str(), &statStruct);
if( addlink != 0) cout << " addlink came back " << endl;
statStruct.st_mode |= addlink;
#else
int actStat = lstat( testDir.c_str(), &statStruct);
#endif

where fstat_win32 now has a graveyard full of attempts: ( When a directory
link is encountered, however, the test succeeeds.)

  void fstat_win32(const string& filepath, int& st_mode)
{
DWORD dwattrib, reparsetag;
DString st;
st=filepath;
#if 1
//
//  This method has not been tested: it will not compile -
GetFileInformationByHandleEx
//  does not get through from the winbase.h header
//
HANDLE hFile;
BOOL success;
DWORD fattrib[2];
hFile = CreateFile( (TCHAR *)st.c_str(),
FILE_GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE,
0,
OPEN_EXISTING,
FILE_FLAG_OPEN_REPARSE_POINT,
  0);
if (hFile == INVALID_HANDLE_VALUE) {
CloseHandle(hFile);
cout << " stat_win32: could not open " + st << endl;
return;
   }
else {
success = GetFileInformationByHandleEx( hFile,
FileAttributeTagInfo,
&fattrib,
sizeof(fattrib));
dwattrib = fattrib[0];
reparsetag = fattrib[1];
}
CloseHandle(hFile);

//dwattrib = GetFileAttributes( (TCHAR *)st.c_str()); // This doesn't
work to find symlinks
if( (dwattrib & FILE_ATTRIBUTE_REPARSE_POINT) != 0 )  {
st_mode |= S_IFLNK;
cout << " fstat_win32: symbolic link detected and flagged!! " <<
filepath ;
}
 else st_mode=0;
#elif 0
DWORD dwlen;
HANDLE hFind;
BOOL foundnext;
WIN32_FIND_DATA FindFileData;
// This doesn't work to find symlinks
hFind = FindFirstFileEx( (TCHAR *) st.c_str(),
 FindExInfoStandard,
 &FindFileData,
 FindExSearchNameMatch, NULL, 0);
if (hFind == INVALID_HANDLE_VALUE)
return;
dwattrib = FindFileData.dwFileAttributes;
if( (dwattrib & FILE_ATTRIBUTE_REPARSE_POINT) != 0 )  {
st_mode |= S_IFLNK;
cout << " fstat_win32: symbolic link detected and flagged!! " <<
filepath ;
dwattrib = FindFileData.dwReserved0;
// IO_REPARSE_TAG_SYMLINK _MOUNT_POINT etc.
}
   FindClose(hFind);
#endif
return;
}
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] TDM-GCC 4.9.2 released

[Greg Jung]

Hi John,
  If you would indulge my questions, I am intrigued by the advice re:
"-fno-keep-inline-dllexport"
flag
because it mentions wxWidgets which I am trying to incorporate into an
already-large program.
Do you know what problem it addresses, is it needed to unclutter a
namespace? Also regarding
TDM, how many hooks into the windows registry does it maintain?  I
un-installed a TDM from a previous system and was dismayed at what seemed
like 2,000 entries in the registry wind-down - am I hallucinating that?

On Mon, Dec 8, 2014 at 7:41 PM, John E. / TDM  wrote:

> Greetings!
>
>
> === TDM-GCC 4.9.2 is now available! ===
>
>
> TDM-GCC is a native binary distribution of the GCC compiler for Windows.
> It targets 64-bit Windows (x86_64-w64-mingw32), or 32-bit Windows
> (i686-w64-mingw32, i686-pc-mingw32), and is mostly compatible with MinGW
> and MinGW-w64. More information and an easy-to-use Windows installer and
> updater are available at .
>
>
>   * With thanks to the MinGW-Builds maintainers for maintaining patch
> lists, libatomic and gnatdll are now included.
>   * Since the 4.8.1 release, TDM-GCC uses POSIX-style threading in the
> GCC runtime libraries, based on the "winpthreads" library. It includes
> patches to incorporate static winpthreads compilation with a shared
> memory region, so your programs won't rely on a pthreads DLL but can
> still share thread handles among DLLs and EXEs.
>   * As always, TDM-GCC includes a few other patches to make it more
> "Windows-friendly": default static runtime linkage, full toolchain
> relocatability, coexisting 64-bit and 32-bit DLLs, and the
> oft-decried-yet-ever-useful shared-memory exception mechanism, among
> others. See the README for details.
>   * Remember to use the "-fno-keep-inline-dllexport" flag to fix memory
> usage problems when linking DLLs with a large number of inline functions
> (such as wxWidgets).
>
>
>  >>> TDM-GCC is available in TWO editions:
> You can choose between the classic TDM 32-bit edition and the *TDM64*
> edition. The TDM64 edition is based on the MinGW-w64 runtime API and the
> x86_64-w64-mingw32 GCC target, and can create both 32-bit and 64-bit
> code, with the "-m32"/"-m64" compiler flags. Please never mix 32-bit
> object files (.o), libraries (.a), DLLs or EXEs with 64-bit versions,
> and don't report it as a bug if you inadvertently do.
>
>
> Alongside the GCC 4.9.2 packages are binary packages of the MinGW-w64
> runtime (based on Git v3.x branch, 2011-11-30 /
> 41cf52b46006658ad17c39ee06ce0adece2ce7bf), binutils (2.24.51 snapshot
> 20140703), and gdb (7.8.1). TDM-GCC includes support for C, C++,
> Fortran, Objective-C/C++, and Ada, as well as support for LTO and the
> OpenMP multithreading extensions.
>
>
> Cheers,
> John E. / TDM
>
>
> --
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] is open MP a problem sometimes?

[Greg Jung]

I've just started an MSYS2 installation, (msys64) and have taken the
pre-built tree from the win-builds project, which includes an
x86_64-w64-mingw32 compiler built with posix thread model, seh exceptions.
 it is gcc version 4.8.2.

  Missing in the compiler-specific directory is the omp.h header

So, even though the compilers would take -fopenmp as a valid option, it
won't compile for openMP.
Does this make things simpler somewhere?   Is openMP a flourish with little
benefit?  Or is it a major flaw in posix/seh
that things wont work right with it?
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mingw/msys configuration

[Greg Jung]

Thanks, that was indeed the tty output log  from running "make" >&
make.out, where a number of
xxx.lo objects were already created and this command was supposed to start
building a shared library.  Following this:

make[1]: *** [magick/libGraphicsMagick.la] Error 1
make[1]: Leaving directory `/mingw/sources/GraphicsMagick-1.3.20/bldshared'
make: *** [all] Error 2

 I went to my Cygwin64 installation, its compiler (x86_w64-pc-cygwin
(posix, 4.8.3, dwarf) had no problems
with GraphicsMagick, and the link had no issues:
== make.out using x86_w64-pc-cygwin:
/bin/sh ./libtool  --tag=CC   --mode=link gcc -O2 -std=gnu99  -fopenmp
-I/usr/local/include -Wall -no-undefined -export-symbols-regex ".*"
 -version-info 15:0:12 -L/opt/local/lib -L/usr/local/lib -L/usr/lib
-L/usr/lib -o magick/libGraphicsMagick.la -rpath
/opt/bld/GraphicsMagick-1.3.20/lib
magick/magick_libGraphicsMagick_la-analyze.lo

   (etc)

 coders/magick_libGraphicsMagick_la-ept.lo
coders/magick_libGraphicsMagick_la-tiff.lo
coders/magick_libGraphicsMagick_la-x.lo
coders/magick_libGraphicsMagick_la-xwd.lo
 filters/magick_libGraphicsMagick_la-analyze.lo -ljbig -llcms2 -ltiff
-lfreetype -ljpeg -lpng15 -lwmflite -lXext -lSM -lICE -lX11 -llzma -lbz2
-lxml2 -lz -lgdi32 -lm -lgomp -lpthread
 (successful)

 using i686-win32-sjlj, 4.8.2)
$ grep -n lpng1 ../bldE/make.out
705:/bin/sh ./libtool  --tag=CC   --mode=link gcc -O2 -mtune=pentium3
-std=gnu99  -fopenmp -I/local32/include -Wall -pthread -no-undefined
-export-symbols-regex ".*"  -version-info 15:0:12 -L/local32/lib
-L/local32/lib -L/local32/lib -o magick/libGraphicsMagick.la -rpath
/build32/GM1.3.20share/lib magick/magick_libGraphicsMagick_la-analyze.lo
magick/magick_libGraphicsMagick_la-annotate.lo
magick/magick_libGraphicsMagick_la-attribute.lo

 (etc)

 coders/magick_libGraphicsMagick_la-ept.lo
coders/magick_libGraphicsMagick_la-tiff.lo
 coders/magick_libGraphicsMagick_la-webp.lo
filters/magick_libGraphicsMagick_la-analyze.lo -lwebp -ltiff -lfreetype
-ljpeg -lpng16 -lwmflite -lbz2 -lxml2 -lz -lgdi32 -lm -lgomp -lpthread
=
(above error.  Looking for libpng16 in usr/local/lib when it was waiting in
/local32/lib)

  Because the two compilers are fed the same line, I'm inclined to believe
improving  the shell environment with msys2 will not help.  I have
downloaded msys2 now, though, and anticipate using it for 64-bit builds
once I'm more comfortable with it.


On Sat, Nov 1, 2014 at 6:57 PM, Ray Donnelly 
wrote:

> I'm tired, corrections inline:
>
> On Sun, Nov 2, 2014 at 1:54 AM, Ray Donnelly 
> wrote:
> > On Sun, Nov 2, 2014 at 1:19 AM, Greg Jung  wrote:
> >> Hi guys,
> >>
> >> I am using mingw-w64 gcc v4.8.2 installed under the /mingw32 directory
> under
> >> mingw and I compile using msys/1.0 shell, or CMAKE from msys using "MSYS
> >> Makefiles".
> >> I adopted this after installing from a recipe and found it worked more
> often
> >> than not in situations where plain mingw/msys (installed on same
> computer)
> >> failed.  So I've been pretty happy with things but as my projects get
> larger
> >> I need a better understanding of the general configuration and what gcc
> >> expects - especially the linker utilities.
> >>
> >> 2 quick questions:
> >>Is MSYS2 really neccessary to work with mingw-m64 compilers? I've
> managed
> >> OK with msys-1.0.
> >
> > No, cmd.exe is enough to work with mingw-w64 compilers, or an IDE such
> > as QtCreator, CodeLite or Eclipse could be used. If you want a bash
> > command line, then MSYS2 is much better than MSYS.
> > Speaking for the core of MSYS2, it is forked from (and re-syncs
> > regularly with) current Cygwin which has ~15 years more bugfixes and
> > features applied to it than MSYS, it has 64bit support (so that dll
> > rebase issues practically vanish) and whereas make -jN (where N>1)
> > fails often with MSYS1 it is reliable on MSYS2 (due to improvements to
> > the core of Cygwin).
> >
> > With regard to the user-space programs, MSYS2 provides bleeding edge
> > versions of build tools such as bash, gnumake, perl, python, git, svn,
> > cmake, gyp etc.
> >
> >>
> >>   I tried to overlay the 4.9.1 gcc-tools distribution on a /mingw32 tree
> >> under my older mingw installation, but the failure of a configure
> (couldn't
> >> determine default exec file) indicates I may need to do something more:
> >> true? if so, what?
> >>
> >> -
> >>   My current problem is from trying to make a shared library in
> >> graphicsMagick,
> >> this line is the first link attempt after compila

[Mingw-w64-public] Mingw/msys configuration

[Greg Jung]

Hi guys,

I am using mingw-w64 gcc v4.8.2 installed under the /mingw32 directory
under mingw and I compile using msys/1.0 shell, or CMAKE from msys using
"MSYS Makefiles".
I adopted this after installing from a recipe and found it worked more
often than not in situations where plain mingw/msys (installed on same
computer) failed.  So I've been pretty happy with things but as my projects
get larger I need a better understanding of the general configuration and
what gcc expects - especially the linker utilities.

2 quick questions:
   Is MSYS2 really neccessary to work with mingw-m64 compilers? I've
managed OK with msys-1.0.

  I tried to overlay the 4.9.1 gcc-tools distribution on a /mingw32 tree
under my older mingw installation, but the failure of a configure (couldn't
determine default exec file) indicates I may need to do something more:
true? if so, what?

-
  My current problem is from trying to make a shared library in
graphicsMagick,
this line is the first link attempt after compilation:
bin/sh ./libtool  --tag=CC   --mode=link gcc -O2 -mtune=pentium3 \
 (more flags) \
 -L/local32/lib -o magick/libGraphicsMagick.la -rpath
/build32/GM1.3.20share/lib \
  (long list of .lo files) \
  magick/magick_libGraphicsMagick_la-analyze.lo \
   XXX..analyze.lo -lwebp -ltiff -lfreetype -ljpeg -lpng16 -lwmflite -lbz2
-lxml2 -lz -lgdi32 -lm -lgomp -lpthread

/bin/grep: /usr/local/lib/libpng16.la: No such file or directory
/bin/sed: can't read /usr/local/lib/libpng16.la: No such file or directory
libtool: link: `/usr/local/lib/libpng16.la' is not a valid libtool archive
---
  I'm guessing webp, freetype, jpeg and tiff were ready to load from the
compiler tree, and png16 was the first library to get
loaded from the library: -L/local32/lib=LDFLAGS  holds all of these but it
went to search  in /usr/local/lib. ???.
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] undefined references

[Greg Jung]

So they are in direct.h ... they used to be found in io.h, as you would get
using MSVC, I presume.

 So why doesn't io.h #include  .. should it?

hmm .. direc.h and io.h should have been included under the following from
filefn.h, which feeds filefn.cpp:

#if defined(__WINDOWS__) && !defined(__WXMICROWIN__)
#if !defined( __GNUWIN32__ ) && !defined( __MWERKS__ ) &&
!defined(__SALFORDC__) && !defined(__WXWINCE__) && !defined(__CYGWIN__)
#include 
#include 
#include 
#endif // __WINDOWS__
#endif // native Win compiler


On Wed, Oct 29, 2014 at 10:23 PM, Yaron Keren  wrote:

> Hi,
>
> These _functions are in  same as Visual C++.
> Maybe filefn.cpp does not #include it?
>
> Yaron
>
>
> 2014-10-30 0:51 GMT+02:00 Greg Jung :
>
>> Hi all,
>>   Just as a matter of example, I run into the following error compiling
>> wxMSW-2.8.12 using mingw/msys- gcc-4.8.2 (sjlj, win32):
>>
>> ../src/common/filefn.cpp: In function 'bool wxMkdir(const wxString&,
>> int)':
>> ../src/common/filefn.cpp:1253:30: error: '_mkdir' was not declared in
>> this scope
>>  if ( wxMkDir(dir.fn_str()) != 0 )
>>   ^
>> ../src/common/filefn.cpp: In function 'bool wxRmdir(const wxString&,
>> int)':
>> ../src/common/filefn.cpp:1278:37: error: '_rmdir' was not declared in
>> this scope
>>  return (wxRmDir(OS_FILENAME(dir)) == 0);
>>
>> upon inspection, filefn.cpp is a real mess of preprocessor directives but
>> it looks like mingw is missing something expected.
>> I found on this page an interesting discussion of this very issue,
>> exactly:
>>
>> https://forums.wxwidgets.org/viewtopic.php?t=29862 :
>>
>> Tue Oct 11, 2011 8:10 pm
>> After more analysis and discussion on de wx-dev mailing list the cause of
>> the problem is clear now:
>>
>> The C interface to msvcrt.dll supplied with the mingw-w64 compilers only
>> defines the mkdir() and rmdir() functions for ANSI paths.
>>
>> The original MinGW defines mkdir(), _mkdir(), rmdir() and _rmdir() for
>> ANSI paths. However, the versions without leading underscore are deprecated
>> by Microsoft as of Visual C++ 2005.
>>
>> Mingw-w64 is using the deprecated versions, which is probably a bug /
>> typo.
>>
>> I provided a patch for filefn.h with a workaround for this problem. Dee
>> http://trac.wxwidgets.org/ticket/13556 for more information.
>>
>>
>> --
>>
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>>
>
>
> --
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] undefined references

[Greg Jung]

Hi all,
  Just as a matter of example, I run into the following error compiling
wxMSW-2.8.12 using mingw/msys- gcc-4.8.2 (sjlj, win32):

../src/common/filefn.cpp: In function 'bool wxMkdir(const wxString&, int)':
../src/common/filefn.cpp:1253:30: error: '_mkdir' was not declared in this
scope
 if ( wxMkDir(dir.fn_str()) != 0 )
  ^
../src/common/filefn.cpp: In function 'bool wxRmdir(const wxString&, int)':
../src/common/filefn.cpp:1278:37: error: '_rmdir' was not declared in this
scope
 return (wxRmDir(OS_FILENAME(dir)) == 0);

upon inspection, filefn.cpp is a real mess of preprocessor directives but
it looks like mingw is missing something expected.
I found on this page an interesting discussion of this very issue, exactly:

https://forums.wxwidgets.org/viewtopic.php?t=29862 :

Tue Oct 11, 2011 8:10 pm
After more analysis and discussion on de wx-dev mailing list the cause of
the problem is clear now:

The C interface to msvcrt.dll supplied with the mingw-w64 compilers only
defines the mkdir() and rmdir() functions for ANSI paths.

The original MinGW defines mkdir(), _mkdir(), rmdir() and _rmdir() for ANSI
paths. However, the versions without leading underscore are deprecated by
Microsoft as of Visual C++ 2005.

Mingw-w64 is using the deprecated versions, which is probably a bug / typo.

I provided a patch for filefn.h with a workaround for this problem. Dee
http://trac.wxwidgets.org/ticket/13556 for more information.
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public