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

I found that gcc4 requires pthreads-w32-*-mingw32-dev and
libpthread-*-mingw32-dll-2. I understand that the latter is needed
for the gcc runtime, but do we really need the pthreads dev files?

See here (lines may wrap):

$ grep pthread /mingw/var/lib/mingw-get/data/*|grep require
/mingw/var/lib/mingw-get/data/mingw32-gcc4.xml:        <requires 
eq="pthreads-w32-*-mingw32-dev.tar" />
/mingw/var/lib/mingw-get/data/mingw32-gcc4.xml:        <requires 
eq="libpthread-*-mingw32-dll-2.tar" />
[...]

The problem I *had* with this was that autoconf/configure of a software
package insisted on linking with pthreads, simply because it found
the existing headers and libs (this software works optionally with
pthreads on U*X systems, but uses native Windows threads on Windows).
Hence, libpthread is not needed when building on Windows.

This (configure problem) is fixed now, but I wanted to point this out
anyway. I'd like to remove pthreads-w32-dev, but (re-)installing gcc
installs it again:

$ mingw-get remove pthreads-w32-dev
...
remove: pthreads-w32-2.8.0-3-mingw32-dev.tar.lzma
  removing release pthreads-w32-2.8.0-3-mingw32-dev.tar.lzma

Okay so far, but:

$ mingw-get install gcc
...
install: gcc-4.5.2-1-mingw32-lic.tar.lzma
  installing gcc-4.5.2-1-mingw32-lic.tar.lzma
install: pthreads-w32-2.8.0-3-mingw32-dev.tar.lzma      <<<<<<
  installing pthreads-w32-2.8.0-3-mingw32-dev.tar.lzma   <<<<<<
install: gcc-core-4.5.2-1-mingw32-bin.tar.lzma
  installing gcc-core-4.5.2-1-mingw32-bin.tar.lzma
install: gcc-4.5.2-1-mingw32-doc.tar.lzma
  installing gcc-4.5.2-1-mingw32-doc.tar.lzma
install: gcc-4.5.2-1-mingw32-lang.tar.lzma
  installing gcc-4.5.2-1-mingw32-lang.tar.lzma

.. installs pthreads-w32.dev again.

BTW: "mingw-get upgrade gcc" does NOT install pthreads-*-dev.


So there are 2 questions:

  - can/should the dependency on pthreads-w32-dev be removed ?
  - why does 'upgrade' not install the listed dependency?

TIA
Albrecht

On 2011-03-31 19:26Z, ni va wrote:
> 
> I am trying to link serproxy 1.2.0 with mingw.
[...]
> INC = \
>   C:/MinGW/msys/1.0/include

Do you really want to build this as an MSYS-dependent application?
If so, are you sure you're using the MSYS toolchain, rather than
the native MinGW one? Have you considered using Cygwin instead?

> LIBS= -LC:/MinGW/msys/1.0/include -lpthread

It seems odd to add an include directory to the linker path. Is
there really a pthread library there?

> clean:
> # NIVA UPDT
> del /F *.o

Why not use 'rm'? Are you using CMD.EXE as your shell for building
an MSYS application?

I've released an further update to the mingw-get-0.2 build series:
https://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get/mingw-get-0.2-alpha-3/

This fixes the bug, recently reported by Charles Wilson, which resulted
in silent failure of the "remove" operation when the default mechanism
for specifying installation paths is employed.

Also incorporated is an initial attempt, based on a patch provided by
Scott Michel, to facilitate use of mingw-get from behind a proxy which
requires explicit user authentication.

All users are advised to upgrade to this release ASAP.

-- 
Regards,
Keith.

"ni va" <niv...@gm...> wrote:

> Those errors'link are coming :
>  gcc -IC:/MinGW/msys/1.0/include -Wall -O2  -o serproxy main.o sio.o sock.o
> thread.o vlist.o cfglib.o config.o string.o pipe.c error.c
>  -LC:/MinGW/msys/1.0/include -lpthread
> || main.o:main.c:(.text+0x73): référence indéfinie vers « _impure_ptr »

I'm not sure about this. Looks like something MSVC specific.

|| main.o:main.c:(.text+0xe5): référence indéfinie vers « select@20 »
|| main.o:main.c:(.text+0x12d): référence indéfinie vers «__WSAFDIsSet@8 »

Add '-lws2_32' to the gcc link command.

--gv 

Hi,

I am trying to link serproxy 1.2.0 with mingw.

I am using this makefile that I have updated from unix'makefile.

#
# File: Linux serproxy makefile
#
# (C)1999 Stefano Busti
#

VERSION = `cat VERSION`

# NIVA ADD
INC = \
  C:/MinGW/msys/1.0/include

SRCS = \
  main.c sio.c sock.c thread.c vlist.c cfglib.c config.c string.c \
  pipe.c error.c

OBJS = \
  main.o sio.o sock.o thread.o vlist.o cfglib.o config.o string.o \
  pipe.c error.c

CC = gcc

ifdef DEBUG
CFLAGS = -I$(INC) -Wall -g -D__UNIX__ -DDEBUG
else
# NIVA ADD
CFLAGS = -I$(INC) -Wall -O2
# CFLAGS = -I$(INC) -Wall -O2 -fomit-frame-pointer -D__UNIX__
endif

ifdef USE_EF
LIBS= -lpthread -lefence
else
# NIVA ADD
LIBS= -LC:/MinGW/msys/1.0/include -lpthread
endif

# Build the program

serproxy: $(SRCS) $(OBJS)
$(CC) $(CFLAGS)  -o serproxy $(OBJS) $(LDFLAGS) $(LIBS)

install: serproxy
cp -f serproxy c:/temp

clean:
# NIVA UPDT
del /F *.o

realclean:
# NIVA UPDT
del /F *.o serproxy *.gz *.zip

dep:
makedepend -Y -- $(CFLAGS) -- $(SRCS) 2&>/dev/null

# DO NOT DELETE

main.o: sio.h sock.h pipe.h thread.h vlist.h cfglib.h config.h error.h
sio.o: sio.h
sock.o: sock.h
thread.o: thread.h
vlist.o: vlist.h
cfglib.o: cfglib.h
config.o: config.h cfglib.h string.h
string.o: string.h
pipe.o: pipe.h sio.h sock.h thread.h
error.o: error.h




Those errors'link are coming :
 gcc -IC:/MinGW/msys/1.0/include -Wall -O2  -o serproxy main.o sio.o sock.o
thread.o vlist.o cfglib.o config.o string.o pipe.c error.c
 -LC:/MinGW/msys/1.0/include -lpthread
|| main.o:main.c:(.text+0x73): référence indéfinie vers « _impure_ptr »
|| main.o:main.c:(.text+0xe5): référence indéfinie vers « select@20 »
|| main.o:main.c:(.text+0x12d): référence indéfinie vers «
__WSAFDIsSet@8 »
|| main.o:main.c:(.text+0x170): référence indéfinie vers «
__WSAFDIsSet@8 »
...
|| main.o:main.c:(.text+0x268): référence indéfinie vers « _impure_ptr
»
...
|| main.o:main.c:(.text+0x74b): référence indéfinie vers « select@20 »




Can somebody help me to link this application please ?
Thank you in advance

Niva

2011/3/31 Charles Wilson <cwi...@us...>:
> On 3/30/2011 11:05 AM, Earnie wrote:
>>> I'd much rather simply "fix" the msys-1.0.dll to abide by the de facto
>>> ("don't mess with errno on success") standard, and punt -- basically,
>>> release perl-5.8.8 with the requirement that users upgrade msys to
>>> 1.0.17, and not patch perl with respect to this issue at all.
>>>
>>
>> Definitely understandable and I agree.
>
> I committed the patch; however, I'll leave it to Cesar to determine when
> to release 1.0.17 -- maybe he has some other patches in his queue he
> wants to get in (like
> http://sourceforge.net/tracker/?func=detail&aid=3081421&group_id=2435&atid=302435)
>
> However, sooner is better than later, as I have to delay msys-perl-5.8.8
> until after the next msys release. :-)
>

Just in case:
perl-5.14 will be released in a week or two, and cygwin perl will be
updated to 5.14 also very soon.

There are only 4 patches outstanding, see my github cygwin branch.

commit e054a87afd770f201f1fe294edb26e56ffd129aa
Merge: e9836db 11883c8
Author: Reini Urban <ru...@x-...>
Date:   Fri Mar 11 16:33:07 2011 +0100

    resolve ext/DynaLoader/DynaLoader_pm.PL

commit a4412ab9449789661b68f90b4299fc372bebf8f9
Author: Reini Urban <ru...@x-...>
Date:   Tue Sep 14 18:06:38 2010 +0200

    Update cygwin hints
    do not use usemymalloc (double size + slow)
    remove deprecated libcygipc info
    remove overlarge stack size

commit 558d351f74c7483e0e21bdc38b42120004228df7
Author: Reini Urban <ru...@x-...>
Date:   Tue Sep 14 18:04:22 2010 +0200

    build man pages on cygwin too

commit 8c17403c0c6abf630a77329b3737af4efd8cb5ab
Author: Reini Urban <ru...@x-...>
Date:   Tue Sep 14 17:54:15 2010 +0200

    Improve cygwin rebase behaviour

    If a dll is updated on cygwin reuse the old imagebase address.
    This solves most rebase errors, esp when updating on core dll's.
-- 
Reini Urban

On 3/30/2011 11:05 AM, Earnie wrote:
>> I'd much rather simply "fix" the msys-1.0.dll to abide by the de facto
>> ("don't mess with errno on success") standard, and punt -- basically,
>> release perl-5.8.8 with the requirement that users upgrade msys to
>> 1.0.17, and not patch perl with respect to this issue at all.
>>
> 
> Definitely understandable and I agree.

I committed the patch; however, I'll leave it to Cesar to determine when
to release 1.0.17 -- maybe he has some other patches in his queue he
wants to get in (like
http://sourceforge.net/tracker/?func=detail&aid=3081421&group_id=2435&atid=302435)

However, sooner is better than later, as I have to delay msys-perl-5.8.8
until after the next msys release. :-)

--
Chuck

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

On 3/30/2011 23:21, Earnie wrote:
> Marcin M. wrote:
>>> hi
>>> i want to build the 64 bit (x86_64-pc-mingw64) mingw on linux
>>> but it wants the package mingwrt-3.18-mingw64.tar.gz which has 404 error
>>> while downloading and i can't find it anywhere
>>> could you help?
>>> --
>>> Pozdrawiam,
>>> Marcin
> 
> MinGW64 team,
> 
> Can you help Marcin please?
> 

I was not aware of a "mingwrt-3.18-mingw64.tar.gz" tarball around, where
is it supposed to come from?

If its really mingw-w64, x86_64-pc-mingw64 is not the same as
x86_64-w64-mingw64. The latter is designed to use mingw-w64 specific
features, while the former is setup for compatibility with mingw.org
(which doesn't quite make sense at the moment, since there is not 64bit
support there yet). The latter triplet is encouraged.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (MingW32)

iEYEARECAAYFAk2T0q0ACgkQp56AKe10wHdetgCfQyQ1DKn33Ud2yUAX5ZBuCKND
YAoAnihu2+6nlXBFHdOQmxY9hAgSCY8/
=5bBq
-----END PGP SIGNATURE-----

On 28/03/11 22:01, Charles Wilson wrote:
> On 3/28/2011 4:39 PM, Keith Marshall wrote:
>> On 28/03/11 17:13, Charles Wilson wrote:
>>> I thought that mingw-get-0.2-alpha-{1,2} was supposed to support
>>> removal operations:
>> 
>> It is, and as the attached session transcript shows, it WJFFM.
>> 
>>> What gives?

Another bug; see below...

>> Dunno.  An incomplete installation manifest, perhaps?  Did you install
>> with an early version of mingw-get, which which may not have recorded
>> the files list?
>  
> Nope, brand new installation, created from scratch. Used cygwin tar to
> unpack mingw-get-0.2-alpha-2-bin.tar.gz, then copied default.xml to
> profile.xml.  (OS is XP64, if that makes a difference).

Okay; found the problem; (XP64 isn't relevant).  Now fixed in CVS...

  unlink( "%R/msys/1.0/bin/perl.exe" )

would not remove c:/MinGW/msys/1.0/bin/perl.exe; (it worked for me
because my profile.xml specified the sysroot prefix explicitly, rather
than rely on expansion of %R, as your default set-up does).

I'll aim for a new release in the next day or two.

-- 
Regards,
Keith.

On 30/03/11 17:17, Marcin M. wrote:
> could you help me?

If you persist in top-posting, then no, but just this one time only:

- The archive you are missing is now distributed as a .tar.lzma, and no
longer as a .tar.gz; you need to adapt your build procedure to account
for that change.

- The w64 team maintain their own independent ML.  While we are happy to
act as a clearing house for w64 issues, you may get a speedier response
by contacting them directly.

-- 
Regards,
Keith.

On 3/30/2011 12:05 PM, LRN wrote:
> probably happens somewhere at the bottom of
> the binary stack (i've checked the script part up to the point where it 
> calls close() builtin, the builtin appears to return 0, wrongly of 
> course), close to the interpreter (either that, or the errno-evaluating 
> part is hidden too well for me to find it), which might mean that the 
> problem lies in some *other* piece of code that gets executed by the 
> interpreter *after* the call to perl_something_IO_whatever_close(), but 
> *before* script-level builtin close() returns.

I think, but am not sure, it's the magic bit of code that makes errno
available to the perl interpreter via $! (it's "magic" because it also
supports modifiers like '$!{ENOENT}' [true iff errno=ENOENT], and
evaluations in a string context automatically call perl's equivalent of
strerror).

However, AFAICT the code that handles $! is decoupled from the return
value processing -- so it doesn't have any knowledge of the fact that,
"well, hey, this system call returned success so I should actually
ignore/reset errno in THIS case, but not others..."

OTOH, agreeing with our consensus on the meaning -- or rather, the lack
thereof -- of errno after success, perl is unambiguous about it:

======================================================================
If used numerically, yields the current value of the C errno variable,
or in other words, if a system or library call fails, it sets this
variable. This means that the value of $! is meaningful only immediately
after a failure:

    if (open my $fh, "<", $filename) {
    # Here $! is meaningless.
    ...
    } else {
    # ONLY here is $! meaningful.
    ...
    # Already here $! might be meaningless.
    }
    # Since here we might have either success or failure,
    # here $! is meaningless.

In the above meaningless stands for anything: zero, non-zero, undef. A
successful system or library call does not set the variable to zero.

If used as a string, yields the corresponding system error string. You
can assign a number to $! to set errno if, for instance, you want "$!"
to return the string for error n, or you want to set the exit value for
the die() operator. (Mnemonic: What just went bang?)
======================================================================

and it is certainly possible that the problematic bits we are seeing are
simply violating that restriction.  But I don't think that's the case
(otherwise, it'd be common to see the "failure" on other platforms, not
just MSYS with its 'strict posix but very surprising' behavior).

Also, one of the consequences of MSys's behavior is that immediately
after a failure (as viewed by a perl client), I get the *wrong* errno.
E.g. if system('app-no-exist.exe') fails because exec() is unable to
locate app-no-exist, I SHOULD see EACCESS, EINVAL, ENOENT, or ENOEXEC.
But instead, I see EBADF (now, granted, perhaps THIS is a simple bug in
perl's system() implementation, where it ought to save errno after a
failed exec, before close()ing the various redirection fd's, and then
restore it  ...)

But...it's one thing to say "well, great, msys's strict standards
conformance is exposing real bugs that should be fixed in the client"
and quite another to say "and there are 1000 of them, and I can spend
months tracking them all down and fixing or hiding them individually" --
or we can make MSYS conform to the de facto behavior of all other unix
platforms with a one line change, and I can move on to something more
fun.  Like doing my taxes.  :-P


But yeah, I've failed to really discover the 'easily fixable' Real
Bug(tm) -- if it is, in fact, 'easily fixable'. And, I don't have any
more time to hunt.

--
Chuck

>
> could you help me?
> 2011/3/30 Earnie <ea...@us...>
>
>> Marcin M. wrote:
>> >> hi
>> >> i want to build the 64 bit (x86_64-pc-mingw64) mingw on linux
>> >> but it wants the package mingwrt-3.18-mingw64.tar.gz which has 404
>> error
>> >> while downloading and i can't find it anywhere
>> >> could you help?
>> >> --
>> >> Pozdrawiam,
>> >> Marcin
>>
>> MinGW64 team,
>>
>> Can you help Marcin please?
>>
>> --
>> Earnie
>> -- http://www.for-my-kids.com
>>
>
>

--
Pozdrawiam,
Marcin

could you help me?
Pozdrawiam,
Marcin Mielniczuk
Linux jest dla ludzi!


2011/3/30 Earnie <ea...@us...>

> Marcin M. wrote:
> >> hi
> >> i want to build the 64 bit (x86_64-pc-mingw64) mingw on linux
> >> but it wants the package mingwrt-3.18-mingw64.tar.gz which has 404 error
> >> while downloading and i can't find it anywhere
> >> could you help?
> >> --
> >> Pozdrawiam,
> >> Marcin
>
> MinGW64 team,
>
> Can you help Marcin please?
>
> --
> Earnie
> -- http://www.for-my-kids.com
>

On 30.03.2011 18:48, Charles Wilson wrote:
> On 3/30/2011 8:53 AM, Earnie wrote:
>> Patches to resolve the issue in perl should
>> be made upstream as well, correct?
> And frankly, "solving" the problem -- rather than just papering over it
> -- is going to be quite challenging.
I had hoped that you would find the problem, but apparently you have 
failed. As did i. Because i've had difficulties in debugging perl with 
gdb. Because perl code is difficult to understand and is full of very 
perl-specific macros, abstractions and acronyms. And because i've 
tracked this phenomena across the call stack by adding lots of printf()s 
and discovered that the actual bug, i.e. interpretation of the (correct) 
return code & errno value, probably happens somewhere at the bottom of 
the binary stack (i've checked the script part up to the point where it 
calls close() builtin, the builtin appears to return 0, wrongly of 
course), close to the interpreter (either that, or the errno-evaluating 
part is hidden too well for me to find it), which might mean that the 
problem lies in some *other* piece of code that gets executed by the 
interpreter *after* the call to perl_something_IO_whatever_close(), but 
*before* script-level builtin close() returns.

Wondering if you guys know the answer to this. Unfortunately, it doesn't seem 
very easy to make a BHO with Mingw, so I had to revert to VC++ (for ATL).

I'm having an issue where I add items to a ComboBox with SendMessage but the 
Combo box row height is still 1 and shows those 2 tiny arrows on the right. 
Sending the message to show a minimum amount of items fails and according to 
MSDN, the number of items showing should be 30 (which is good enough), but 
that isn't happening. Test machine is XP SP3 with IE8.

// Resource
    COMBOBOX        IDC_COUNTRY,70,45,143,30,CBS_DROPDOWNLIST | WS_VSCROLL | 
WS_TABSTOP

      // Add countries to combo box on init
      control = GetDlgItem(hwndDlg, IDC_COUNTRY);
      for (i = 0; i < sizeof(*countryList); i++) {
        SendMessage(control, CB_ADDSTRING, 0, (LPARAM)countryList[i]);
      }

Thanks

Marcin M. wrote:
>> hi
>> i want to build the 64 bit (x86_64-pc-mingw64) mingw on linux
>> but it wants the package mingwrt-3.18-mingw64.tar.gz which has 404 error
>> while downloading and i can't find it anywhere
>> could you help?
>> --
>> Pozdrawiam,
>> Marcin

MinGW64 team,

Can you help Marcin please?

-- 
Earnie
-- http://www.for-my-kids.com

Charles Wilson wrote:
> 
> Honestly, I just don't have time to tilt at this windmill anymore. By
> MSys insisting on violating the de facto standard behavior ("well, it's
> allowed by the de jure POSIX standard, so there! Pppbbbbhh!") it's just
> making life harder for me.
> 
> I'd much rather simply "fix" the msys-1.0.dll to abide by the de facto
> ("don't mess with errno on success") standard, and punt -- basically,
> release perl-5.8.8 with the requirement that users upgrade msys to
> 1.0.17, and not patch perl with respect to this issue at all.
> 

Definitely understandable and I agree.

-- 
Earnie
-- http://www.for-my-kids.com

> hi
> i want to build the 64 bit (x86_64-pc-mingw64) mingw on linux
> but it wants the package mingwrt-3.18-mingw64.tar.gz which has 404 error
> while downloading and i can't find it anywhere
> could you help?
> --
> Pozdrawiam,
> Marcin
>

On 3/30/2011 8:53 AM, Earnie wrote:
> A strong case has been made for this change but the fact is the perl
> code is still wrong based on the documented function of fclose.

The culprit is actually MSys' close() implementation, which is used
under the hood by its implementation of fclose, as well (I think).

Yes, but...apparently MSys is the only platform on which close() behaves
in this legal, but non-intuitive, manner.  When the de facto standard
behavior differs from the de jure standard behavior, it just makes life
harder to insist on "fixing" all extant clients, like perl, that appear
to depend on the de facto, rather than the de jure, standard.

> With
> this statement I am not saying this patch should not be applied to MSYS,
> in fact, I think it should.

That was my understanding...but I think Cesar was waiting for other
opinions.  I gave mine; and a push for a 1.0.17 containing that fix to
come out soon.

> Patches to resolve the issue in perl should
> be made upstream as well, correct?

In perl-5.8.8, when current perl development is on 5.12.x or 6.0/parrot?
 For a bug that is exposed only on a "walled garden" private platform
like msys?  No, I don't think so.

And frankly, "solving" the problem -- rather than just papering over it
-- is going to be quite challenging.  It seems that there is a lot of
code "out there" that assumes successful system calls don't 'mess with'
the value of errno.  As it happens, some of the errno issues LRN and I
see with perl are bubbled up from the underlying zlib and bzip2 libraries.

I used the attached patch (and reverting the other EBADF "fix"), with
the following results:
	#1: there was NO direct access to msys's close() function, EXCEPT via
the msys_close() wrapper, by perl, libperl, or any of its extension code
*compiled as part of the perl build* [1]. This actually required a lot
of distributed patching, and isn't extensible to user-installed perl
modules.
	#2: It adds a new export, msys_close() to the libperl API, which we'll
need to maintain in perpetuity.
	#3: And it didn't fix the problem with the perl zlib and bzip2
extensions, because they delegate to the respective library code, which
internally call msys's close(), borking up errno.  There's no way a perl
wrapper around its own calls to close() can fix that.  So "fixing" this
means following a lot more rabbit trails in the code, in a lot more places.

So it looks like even "papering over" the bug is not entirely
straightforward, either.  I'll need to go digging in to zlib and libbz2
next. And who knows how many other libraries...and since msys::fclose
uses msys::close, I probably need to extend the "paper over" patch to
wrap fclose as well as close.  And socket(). and connect(). and anything
else that might, inside its msys implementation, also call close()
during successful operation.  And track down all uses of THOSE functions
in the dependent libraries as well.


[1] that is, if a perl extension links against a pre-compiled DLL such
as libgdbm, zlib, libcrypt, or libbz2...and THAT dll already calls
close() on its own, then there's nothing I can do about that from inside
perl.


OTOH, the attached patch did fix the observed errors with running the
autoconf test suite, so that's something.


Honestly, I just don't have time to tilt at this windmill anymore. By
MSys insisting on violating the de facto standard behavior ("well, it's
allowed by the de jure POSIX standard, so there! Pppbbbbhh!") it's just
making life harder for me.

I'd much rather simply "fix" the msys-1.0.dll to abide by the de facto
("don't mess with errno on success") standard, and punt -- basically,
release perl-5.8.8 with the requirement that users upgrade msys to
1.0.17, and not patch perl with respect to this issue at all.

--
Chuck

I have MSYS installed and when I type "which touch" it gives me  /bin/touch.exe.
________________________________________
From: Earnie [ea...@us...]
Sent: Wednesday, March 30, 2011 8:37 AM
To: MinGW Users List
Subject: Re: [Mingw-users] (no subject)

 wrote:
> I am trying to build mingw cross compiler on windows for target= sparc64-sun-solaris2.10 and I got error message
>  during gcc build using gcc-core-3.4.2-20040916-1-src.tar.gz
>
> make[1]: Entering directory `/c/mingw/gcc-sparc64-sun-solaris2.10/libiberty'
> if [ x"" != x ] && [ ! -d pic ]; then \
>           mkdir pic; \
>         else true; fi
> touch stamp-picdir
> make[1]: touch: Command not found
> make[1]: *** [stamp-picdir] Error 127
> make[1]: Leaving directory `/c/mingw/gcc-sparc64-sun-solaris2.10/libiberty'
> make: *** [all-libiberty] Error 2
>
> I used build-cross.sh script.
> Any suggestions?

If you installed a standard MSYS core system then you should have touch
already.  If you are using something else, then you need to go to the
support for that something else.  In other words, you need to tell us
more about your environment.

--
Earnie
-- http://www.for-my-kids.com

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
MinGW-users mailing list
Min...@li...

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:min...@li...?subject=unsubscribe

Simson Garfinkel wrote:
> I think that they are false positives. Does anybody know?

So do I but you could have infected it on your own.  There are hundreds
to thousands of downloads of our files and you are the first to mention
this one.

-- 
Earnie
-- http://www.for-my-kids.com

All,

I'm getting virus scanner errors from libgnurx-0.dll which is apparently part of the mingw distribution. You can view the report at:

	http://www.virustotal.com/file-scan/report.html?id=9a74247550e6d32dc07865e911d21b0c79088af1c07b60e1b3d8fe8825ee8f5b-1300913741

Since most of the errors are "generic malware" and heuristic errors, I think that they are false positives. Does anybody know?

Simson

Charles Wilson wrote:

> 
> The change to the msys dll was a one-liner:
> 
> Index: winsup/cygwin/syscalls.cc
> ===================================================================
> RCS file: /cvsroot/mingw/msys/rt/src/winsup/cygwin/syscalls.cc,v
> retrieving revision 1.18
> diff -u -p -r1.18 syscalls.cc
> --- winsup/cygwin/syscalls.cc   28 Dec 2009 22:07:32 -0000      1.18
> +++ winsup/cygwin/syscalls.cc   28 Mar 2011 23:35:59 -0000
> @@ -507,7 +507,6 @@ _close (int fd)
>      {
>        SetResourceLock (LOCK_FD_LIST,WRITE_LOCK|READ_LOCK," close");
>        res = cygheap->fdtab[fd]->close ();
> -      fsync(fd);
>        cygheap->fdtab.release (fd);
>        ReleaseResourceLock (LOCK_FD_LIST,WRITE_LOCK|READ_LOCK," close");
>      }
> 

A strong case has been made for this change but the fact is the perl
code is still wrong based on the documented function of fclose.  With
this statement I am not saying this patch should not be applied to MSYS,
in fact, I think it should.  Patches to resolve the issue in perl should
be made upstream as well, correct?

-- 
Earnie
-- http://www.for-my-kids.com

 wrote:
> I am trying to build mingw cross compiler on windows for target= sparc64-sun-solaris2.10 and I got error message
>  during gcc build using gcc-core-3.4.2-20040916-1-src.tar.gz
> 
> make[1]: Entering directory `/c/mingw/gcc-sparc64-sun-solaris2.10/libiberty'
> if [ x"" != x ] && [ ! -d pic ]; then \
>           mkdir pic; \
>         else true; fi
> touch stamp-picdir
> make[1]: touch: Command not found
> make[1]: *** [stamp-picdir] Error 127
> make[1]: Leaving directory `/c/mingw/gcc-sparc64-sun-solaris2.10/libiberty'
> make: *** [all-libiberty] Error 2
> 
> I used build-cross.sh script.
> Any suggestions?

If you installed a standard MSYS core system then you should have touch
already.  If you are using something else, then you need to go to the
support for that something else.  In other words, you need to tell us
more about your environment.

-- 
Earnie
-- http://www.for-my-kids.com

________________________________
I am trying to build mingw cross compiler on windows for target= sparc64-sun-solaris2.10 and I got error message
 during gcc build using gcc-core-3.4.2-20040916-1-src.tar.gz

make[1]: Entering directory `/c/mingw/gcc-sparc64-sun-solaris2.10/libiberty'
if [ x"" != x ] && [ ! -d pic ]; then \
          mkdir pic; \
        else true; fi
touch stamp-picdir
make[1]: touch: Command not found
make[1]: *** [stamp-picdir] Error 127
make[1]: Leaving directory `/c/mingw/gcc-sparc64-sun-solaris2.10/libiberty'
make: *** [all-libiberty] Error 2

I used build-cross.sh script.
Any suggestions?

Thanks,
Michael Alperovitch