dos2unix

Hi,

If there is interest I'm willing to package and maintain "dos2unix" for 
MinGW and MSYS. The version that I maintain is used in major Linux 
distributions and since Apr 2011 also standard on Cygwin. See 
http://waterlan.home.xs4all.nl/dos2unix.html

On Cygwin it replaced the Cygutils' version of dos2unix. Msys/MinGW also 
has the Cygutils version.

If you don't want it, that's also fine with me.

best regards,

--

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/

GDB 7.4

Hi All,

I've packaged GDB 7.4 using mgwport which resulted in gdb being split
in to 'gdb' and 'gdb-python'.  I'm assuming this necessitates a
migw32-gdb-python.xml be added to the mingw-get catalog with the
appropriate changes to mingw32-package-list.xml?

Chris

--

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

*** ERROR: mgwport internal error: __init_relocation called too early.

Hi,

I try to build a dos2unix mingw package with mgwport, but I get the 
following error:

waterlan <at> B2 ~/src/mingw/dos2unix/src
$ mgwport dos2unix-5.3.2-1.mgwport almostall
*** ERROR: mgwport internal error: __init_relocation called too early.

I tried mgwport 0.10.5 and 0.10.6.

You can find my input files here:
http://waterlan.home.xs4all.nl/mingw/dos2unix/

best regards,

--

-- 
Erwin Waterlander
http://waterlan.home.xs4all.nl/

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

overriding inst_target in mgwport

Hi Chuck,

How so I go about overriding inst_target with mgwport?  GDB has a
'install-gdb' target that does not install all the bfd stuff (as
opposed to using the 'install' target that installs everything).  I
tried setting inst_target in the mgwport file directly but it seemed
to have no effect.

Thank you,

Chris

--

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

mgwport and multiple builds

Hi Chuck,

I'm trying to package gdb 7.4 using mgwport and I'm at a bit of loss
as to how I package it with 2 different builds (i.e. the python build
and the non-python build).  Any idea how I could handle this?  Do I
need to break it into 2 packages (i.e. gdb and gdb-python)?

Cheers,

Chris

--

-- 
Chris Sutcliffe
http://emergedesktop.org
http://www.google.com/profiles/ir0nh34d

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2

www.mingw.org/Welcome_to_MinGW_org

I think we need new wording on this page.  In particular we need to
remove mingwPORT.  Is someone here up to the challenge?

--

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d

Re: Fwd: src/winsup/w32api .cvsignore ChangeLog lib/Mak ...

On 17/01/12 12:32, Chris Sutcliffe wrote:
>> I will assert,
>> however, that if configure must remain in CVS -- hopefully as no
>> more than a temporary measure -- then there MUST be only one
>> nominated maintainer, with sole responsibility for regenerating
>> and committing it as required; as package maintainer, I guess
>> that would have to be you, Chris, and you'll need to keep a
>> watching brief on the commit notifications, for configure.ac
>> changes.
> 
> Agreed, I accept the responsibility of making sure that configure is
> up to date.  However, I would argue that if someone makes a change
> that requires configure to be regenerated, they would need to
> regenerate configure to make use of the change themselves.  That being
> the case, is it unreasonable to expect them to check in the
> regenerated configure?

Been there; done that; got the tee-shirt; don't want to go back.  Why?
This is a predominant reason why it's a really bad idea to keep a
generated configure script in CVS: 50 to 100 lines of configure.ac +
aclocal.m4 can easily blow up to 10, 20, even 30,000 lines of generated
configure script, and it's very sensitive to even a one point change in
patchlevel of the generating autoconf code.  Two developers, with even
only slightly different autoconf versions can oh so easily get into a
recurring merge conflict.  Believe me, you don't want to try to resolve
such a conflict by hand editing.  You may work around it by discarding
your local copy, replacing with a clean check out, and regenerate, but
the problem is likely to come back.  It becomes frustrating.  Best is to
avoid the problem entirely, by not keeping the generated script in CVS
at all; next best, (and a long way behind), is to have only one person

Re: Fwd: src/winsup/w32api .cvsignore ChangeLog lib/Mak ...

On Tue, Jan 17, 2012 at 7:32 AM, Chris Sutcliffe wrote:
> Hi Keith,
>
> On 16 January 2012 22:24, Keith Marshall wrote:
>> On 16/01/12 22:05, Chris Sutcliffe wrote:
>>> asking that it not be put in the .cvsignore and removed the
>>> repository.
>>
>> Well, I think Corinna has made a terrible choice here -- and a heavy rod
>> for your back, Chris;  keeping generated files, such as configure, in
>> any CMS is a right royal PITA.  Corinna's reversion of my patch >
>> confused my own CVS sandbox, to the extent that it believed configure
>> existed BOTH as an untracked file polluting the workspace, and
>> simultaneously as a tracked file, with a merge conflict.
>>
>> I don't agree with Corinna's decision, but I've no intention of becoming
>> embroiled in a commit/revert war over the issue.  I will assert,
>> however, that if configure must remain in CVS -- hopefully as no more
>> than a temporary measure -- then there MUST be only one nominated
>> maintainer, with sole responsibility for regenerating and committing it
>> as required; as package maintainer, I guess that would have to be you,
>> Chris, and you'll need to keep a watching brief on the commit
>> notifications, for configure.ac changes.
>
> Agreed, I accept the responsibility of making sure that configure is
> up to date.  However, I would argue that if someone makes a change
> that requires configure to be regenerated, they would need to
> regenerate configure to make use of the change themselves.  That being
> the case, is it unreasonable to expect them to check in the
> regenerated configure?

GCC pkgbuild.ini

Cesar,

Is there some reason we need lib/gcc/mingw32/$v/include/c++ in the
gcc-core file?  You include it for both 4.6.1-2 and 4.6.2-1.

Also is there some reason you now include
lib/gcc/mingw32/$v/include/finclude in the gcc-core file for 4.6.2-1?
You had --excluded it before.

Regards,
--

-- 
Earnie
-- https://sites.google.com/site/earnieboyd

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

GCC's default link order

Hi All,

I've been working with Yongwei Wu to incorporate a patch the includes
MBCS support into putc / putchar (as apparently the MS implementation
is broken).  To that end, Yongwei added new implementations of putc /
putchar into mingwex.  The issue I've run in to is that with the
latest GCC (and possibly older releases as well), the default link
order picks up the mingwex implementation of putc / putchar first,
before the the msvcrt implementation which causes issues (link
failures) for the 'general' case (where the user wants to use the MS
supplied putc / putchar):

-lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt -ladvapi32
-lshell32 -luser32 -lkernel32 -lmingw32 -lgcc_eh -lgcc -lmoldname
-lmingwex -lmsvcrt c:/mingw/bin/../lib/gcc/mingw32/4.6.2/crtend.o

Shouldn't -lmingwex be after -lmsvcrt?  Yongwei also raises a good
point, in that -lkernel32 should probably be added to the end of the
default link list as well:

The reason why the new putc makes libgcc_eh use additional functions
from kernel32 is that I used static __thread variables. By default,
libgcc_eh is linked before libmingwex, then libkernel32 satisfies the
initial link need of libgcc_eh; libgcc_eh appears again to provide the
additional needed functions for using __thread in libmingex, but no
libkernel32 again to provide the missing functions.

Putting kernel32 at the end of auto-linked libraries solves such
issues and is very reliable: import libraries do not introduce more
dependencies (while libraries like libgcc_eh and libmingwex do).

Re: mingwrt and w32api build system clean-up

------------------------------------------------------------------------------
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox

_______________________________________________
MinGW-dvlpr mailing list
MinGW-dvlpr@...
https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr