Automake and swig

Building cmake with MSYS and mingw

Hello

I am trying to build the package cmake ( see 
http://www.cmake.org/HTML/Index.html ) using Mingw 2 and 
MSYS.  The package uses ./configure and this fails.  This is 
because it has a define for CYGWIN but not one for MSYS, and it 
therefore thinks it is in a Linux environment, not a Win32 one.

Questions.

1. Is there something defined specifically for the MSYS 
environment and if so what is it?

2. What is it that is different between MSYS and CYGWIN so that I 
can change the cmake code to compile with MSYS?

I am sending this to both MSYS and Cmake lists.

Thank you

John Fletcher

-------------------------------------------------------------------
Dr John P. Fletcher          Tel: (44) 121 359 3611 ext 4625
Chemical Engineering and Applied Chemistry (CEAC),
School of Engineering and Applied Science (SEAS),
Aston University,            Fax: (44) 121 359 4094
Aston Triangle,              Email: J.P.Fletcher@...
BIRMINGHAM B4 7ET  U.K.      CEAC Web site http://www.ceac.aston.ac.uk/

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Automake and swig

Brian Kropf wrote:
> Has anyone gotten swig to compile using msys?  I downloaded the cvs version
> (trying for ruby modules) and it complains about not having automake 1.7.2
> 

Grumble, grumble.  I'll upload a new version of msysDTK soon.

You can also ``touch'' files in this order.

aclocal.m4 (all of them)
Makefile.in (all of them)
configure (all of them)
config.h.in (or whatever it's called in the swig package) (all of them).

>  
> 
> My real question is whether I can just install the newer version of automake
> without using the msys developer package? I have msys 1.08, msys dtk, gcc
> 3.21 and winxp.
> 
> 

I don't know.  Automake is script only binary so you could possibly
``configure --prefix=/usr --host=msys --build=msys --target=msys''
and it work.  You'll just have to try.

Earnie.

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Building cmake with MSYS and mingw

John Fletcher wrote:
> Hello
> 
> I am trying to build the package cmake ( see 
> http://www.cmake.org/HTML/Index.html ) using Mingw 2 and 
> MSYS.  The package uses ./configure and this fails.  This is 
> because it has a define for CYGWIN but not one for MSYS, and it 
> therefore thinks it is in a Linux environment, not a Win32 one.
> 
> Questions.
> 
> 1. Is there something defined specifically for the MSYS 
> environment and if so what is it?
> 
> 2. What is it that is different between MSYS and CYGWIN so that I 
> can change the cmake code to compile with MSYS?
> 
> I am sending this to both MSYS and Cmake lists.
> 

The default use of MSYS is to help porters execute configure which 
requires a POSIX/Bourne compatible environment.  However, at the moment, 
programs that read scripts such as perl, make, CMake, etc that are 
likely to read POSIX style paths need to be built for the MSYS runtime 
in order to function nicely.  To accomplish this there exists an 
msysDVLPR alpha package on the SF project files page for MinGW.  Install 
it into the top level MSYS directory, ``cd / && tar -zxf ...msysDVLPR...''.

Now your set up to be able to build a CMake that is dependent on the 
msys-1.0.dll runtime.  Execute ``msysdvlpr'' to switch your system 
identification and default PATH.  Uname will now return MSYS as the 
system instead of MINGW32 as the system.  This is done in a new command 
window that will open.  I never meant MSYS to be an official host, 
target or build system so I've never added it to the config.guess and 
config.sub files officially, so you'll need to modify config.guess and 
config.sub to add these.  Simply copy the cygwin entries and modify 
cygwin to msys.

Now comes the build, gcc will identify the system as __MSYS__.  So you 
can either add __MSYS__ whereever you find __CYGWIN__ or you can ``make 
CC="gcc -D__CYGWIN__"''.

Earnie.

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: Snapshot: MSYS-1.0.9-2003.01.26-1.exe

Nicolas Weber wrote:
> Earnie Boyd wrote:
> 
>> I forgot to notify the list.
>>
>> This snapshot ``fixes'' the an issue with an occasional sh.exe.stackdump.
>>
>> file: http://prdownloads.sf.net/mingw/MSYS-1.0.9-2003.01.26-1.exe
>>
>> Earnie.
> 
> 
> Is my msys.bat suggestion included?
> 

FYI, I've modified the CVS version of msys.bat and updated my object store.

Earnie.

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

RE: Automake and swig

Thanks Earnie, I downloaded and installed the newer version of automake
without a hitch, and it seems to work wonders for swig.

-brian

-----Original Message-----
From: Earnie Boyd [mailto:earnie_boyd@...] 
Sent: Monday, February 03, 2003 7:47 AM
To: Brian Kropf
Cc: mingw-msys@...
Subject: Re: [Mingw-msys] Automake and swig

Brian Kropf wrote:
> Has anyone gotten swig to compile using msys?  I downloaded the cvs
version
> (trying for ruby modules) and it complains about not having automake 1.7.2
> 

Grumble, grumble.  I'll upload a new version of msysDTK soon.

You can also ``touch'' files in this order.

aclocal.m4 (all of them)
Makefile.in (all of them)
configure (all of them)
config.h.in (or whatever it's called in the swig package) (all of them).

>  
> 
> My real question is whether I can just install the newer version of
automake
> without using the msys developer package? I have msys 1.08, msys dtk, gcc
> 3.21 and winxp.
> 
> 

I don't know.  Automake is script only binary so you could possibly
``configure --prefix=/usr --host=msys --build=msys --target=msys''
and it work.  You'll just have to try.

Earnie.

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

The Secret advertising technique AOL and Microsoft use!

Re: rxvt in MSYS 1.0.8 crash on beep on WinXP

In a message dated 1/27/2003 2:20:16 AM Eastern Standard Time,
coder_infidel@... writes:
> >Anyone know how I might fix this?  I would be willing to
> >debug rxvt/MSYS if someone let me know how to do this..
> 
> I don't know how it might be fixed, but I can help you build a debug version 
> of the MSYS DLL which would be a start.

I have built a debug version of the MSYS DLL.  Unfortunately,
the debugging information generated isn't really doing much
for me.  As usual, I really have no idea what I'm doing.

Can anyone tell me the next step in debugging this thing
is?

I'm on pentium 4 256mb WinXP pro, using current release MSYS
stuff.  I've had this problem for months, maybe a year, maybe
even more (for as long as I've been using MSYS i think).

Problem description: I open up a debugging session of MSYS
with rxvt.  I press Ctrl-W, which normally would generate
a beep, but due to my bug, it locks up.  When using the
debugging DLL, I get the output which I have appended to this
message.  After the last line of that output, no more
output is generated (the application has locked up).

Where do I go from here?

Thanks,

AaronWL

00064688    1486.76079893    [3052] MsYs0000009C 100 336283859 [main] sh 2720
fhandler_tty_common::__release_output_mutex: released at int fhandler_tty_slave::write(const
void *, unsigned int):631, osi 0    
00064689    1486.76088972    [3052] MsYs00000096 100 336284042 [main] sh 2720
fhandler_tty_common::__release_output_mutex:   for int fhandler_tty_slave::write(const void *,
unsigned int):588 (main)    
00064690    1486.76100650    [3052] MsYs00000041 80 336284138 [main] sh 2720 _write: 1 = write (2, 0xA010370,
1)    
00064691    1486.76105064    [3052] MsYs00000053 10 336284247 [main] sh 2720 _read: read (0, 0x22F463, 1)
blocking, sigcatchers 19    
00064692    1486.77032081    [1540] MsYs0000004C 200 337615829 [select_pipe] rxvt 1540 peek_pipe:
/dev/ptmx, ready for read    
00064693    1486.77045965    [1540] MsYs00000055 200 337616414 [main] rxvt 1540 select_stuff::wait: woke
up.  wait_ret 1.  verifying    
00064694    1486.77056050    [1540] MsYs00000051 200 337616556 [main] rxvt 1540 set_bits: me 0xA032318,
testing fd 4 (/dev/ptmx)    
00064695    1486.77064403    [1540] MsYs00000032 200 337616648 [main] rxvt 1540 set_bits: ready 1    
00064696    1486.77079824    [1540] MsYs0000003D 200 337616729 [main] rxvt 1540 select_stuff::wait: gotone
1    
00064697    1486.77088401    [1540] MsYs00000040 200 337616809 [main] rxvt 1540 select_stuff::wait:
returning 0    
00064698    1486.77098626    [1540] MsYs00000050 200 337616888 [main] rxvt 1540 select_stuff::cleanup:
calling cleanup routines    
00064699    1486.77107789    [1540] MsYs0000004F A0000 337616987 [main] rxvt 1540 export_free:
(0xA032360), called by 7102F648    
00064700    1486.77116365    [1540] MsYs00000039 200 337617082 [main] rxvt 1540 peek_pipe: already ready    
00064701    1486.77124579    [1540] MsYs00000051 200 337617167 [main] rxvt 1540 set_bits: me 0xA032318,
testing fd 4 (/dev/ptmx)    
00064702    1486.77133239    [1540] MsYs00000032 200 337617252 [main] rxvt 1540 set_bits: ready 1    
00064703    1486.77141508    [1540] MsYs00000046 200 337617337 [main] rxvt 1540 peek_windows: window 3(0x0)
not ready    
00064704    1486.77149805    [1540] MsYs00000040 200 337617421 [main] rxvt 1540 select_stuff::poll:
returning 1    
00064705    1486.77157963    [1540] MsYs00000050 200 337617504 [main] rxvt 1540 select_stuff::cleanup:
calling cleanup routines    
00064706    1486.77166400    [1540] MsYs00000055 200 337617586 [main] rxvt 1540
select_stuff::~select_stuff: deleting select records    
00064707    1486.77179586    [1540] MsYs0000004F A0000 337617669 [main] rxvt 1540 export_free:
(0xA032318), called by 7102F648    
00064708    1486.77189419    [1540] MsYs0000004F A0000 337617754 [main] rxvt 1540 export_free:
(0xA0322D0), called by 7102F648    
00064709    1486.77200678    [1540] MsYs0000005A 10 337617892 [main] rxvt 1540 _read: read (4, 0x413200,
1024) nonblocking, sigcatchers 5    
00064710    1486.77212160    [1540] MsYs00000045 200 337618006 [main] rxvt 1540 peek_pipe: /dev/ptmx, ready
for read    
00064711    1486.77221071    [1540] MsYs00000058 100 337618121 [main] rxvt 1540
fhandler_pty_master::process_slave_output: bytes read 1    
00064712    1486.77229732    [1540] MsYs00000057 100 337618213 [main] rxvt 1540
fhandler_pty_master::process_slave_output: returning 1    
00064713    1486.77238588    [1540] MsYs00000062 10 337618300 [main] rxvt 1540 _read: 1 = read (4</dev/ptmx>,
0x413200, 1024), bin 4096, errno 11    
00064714    1486.77248589    [1540] MsYs0000005A 10 337618389 [main] rxvt 1540 _read: read (4, 0x413201,
1023) nonblocking, sigcatchers 5    
00064715    1486.77257333    [1540] MsYs0000006D 40 337618487 [main] rxvt 1540 tty::slave_alive: TRACE_IN:
../../../../msys/rt/src/winsup/cygwin/tty.cc, 302    
00064716    1486.77267809    [1540] MsYs00000067 40 337618577 [main] rxvt 1540 tty::alive: TRACE_IN:
../../../../msys/rt/src/winsup/cygwin/tty.cc, 316    
00064717    1486.77309379    [1540] MsYs00000063 10 337618680 [main] rxvt 1540 _read: -1 = read
(4</dev/ptmx>, 0x413201, 1023), bin 4096, errno 11    

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Re: rxvt in MSYS 1.0.8 crash on beep on WinXP

I'll take a look at the code this refers to and get back with you.

Earnie.

AWLaFramboise@... wrote:
> In a message dated 1/27/2003 2:20:16 AM Eastern Standard Time,
coder_infidel@... writes:
> 
>>>Anyone know how I might fix this?  I would be willing to
>>>debug rxvt/MSYS if someone let me know how to do this..
>>
>>I don't know how it might be fixed, but I can help you build a debug version 
>>of the MSYS DLL which would be a start.
> 
> 
> I have built a debug version of the MSYS DLL.  Unfortunately,
> the debugging information generated isn't really doing much
> for me.  As usual, I really have no idea what I'm doing.
> 
> Can anyone tell me the next step in debugging this thing
> is?
> 
> I'm on pentium 4 256mb WinXP pro, using current release MSYS
> stuff.  I've had this problem for months, maybe a year, maybe
> even more (for as long as I've been using MSYS i think).
> 
> Problem description: I open up a debugging session of MSYS
> with rxvt.  I press Ctrl-W, which normally would generate
> a beep, but due to my bug, it locks up.  When using the
> debugging DLL, I get the output which I have appended to this
> message.  After the last line of that output, no more
> output is generated (the application has locked up).
> 
> Where do I go from here?
> 
> Thanks,
> 
> AaronWL
> 
> 
> 00064688    1486.76079893    [3052] MsYs0000009C 100 336283859 [main] sh 2720
fhandler_tty_common::__release_output_mutex: released at int fhandler_tty_slave::write(const
void *, unsigned int):631, osi 0    
> 00064689    1486.76088972    [3052] MsYs00000096 100 336284042 [main] sh 2720
fhandler_tty_common::__release_output_mutex:   for int fhandler_tty_slave::write(const void *,
unsigned int):588 (main)    
> 00064690    1486.76100650    [3052] MsYs00000041 80 336284138 [main] sh 2720 _write: 1 = write (2, 0xA010370,
1)    
> 00064691    1486.76105064    [3052] MsYs00000053 10 336284247 [main] sh 2720 _read: read (0, 0x22F463, 1)
blocking, sigcatchers 19    
> 00064692    1486.77032081    [1540] MsYs0000004C 200 337615829 [select_pipe] rxvt 1540 peek_pipe:
/dev/ptmx, ready for read    
> 00064693    1486.77045965    [1540] MsYs00000055 200 337616414 [main] rxvt 1540 select_stuff::wait: woke
up.  wait_ret 1.  verifying    
> 00064694    1486.77056050    [1540] MsYs00000051 200 337616556 [main] rxvt 1540 set_bits: me 0xA032318,
testing fd 4 (/dev/ptmx)    
> 00064695    1486.77064403    [1540] MsYs00000032 200 337616648 [main] rxvt 1540 set_bits: ready 1    
> 00064696    1486.77079824    [1540] MsYs0000003D 200 337616729 [main] rxvt 1540 select_stuff::wait:
gotone 1    
> 00064697    1486.77088401    [1540] MsYs00000040 200 337616809 [main] rxvt 1540 select_stuff::wait:
returning 0    
> 00064698    1486.77098626    [1540] MsYs00000050 200 337616888 [main] rxvt 1540 select_stuff::cleanup:
calling cleanup routines    
> 00064699    1486.77107789    [1540] MsYs0000004F A0000 337616987 [main] rxvt 1540 export_free:
(0xA032360), called by 7102F648    
> 00064700    1486.77116365    [1540] MsYs00000039 200 337617082 [main] rxvt 1540 peek_pipe: already ready    
> 00064701    1486.77124579    [1540] MsYs00000051 200 337617167 [main] rxvt 1540 set_bits: me 0xA032318,
testing fd 4 (/dev/ptmx)    
> 00064702    1486.77133239    [1540] MsYs00000032 200 337617252 [main] rxvt 1540 set_bits: ready 1    
> 00064703    1486.77141508    [1540] MsYs00000046 200 337617337 [main] rxvt 1540 peek_windows: window
3(0x0) not ready    
> 00064704    1486.77149805    [1540] MsYs00000040 200 337617421 [main] rxvt 1540 select_stuff::poll:
returning 1    
> 00064705    1486.77157963    [1540] MsYs00000050 200 337617504 [main] rxvt 1540 select_stuff::cleanup:
calling cleanup routines    
> 00064706    1486.77166400    [1540] MsYs00000055 200 337617586 [main] rxvt 1540
select_stuff::~select_stuff: deleting select records    
> 00064707    1486.77179586    [1540] MsYs0000004F A0000 337617669 [main] rxvt 1540 export_free:
(0xA032318), called by 7102F648    
> 00064708    1486.77189419    [1540] MsYs0000004F A0000 337617754 [main] rxvt 1540 export_free:
(0xA0322D0), called by 7102F648    
> 00064709    1486.77200678    [1540] MsYs0000005A 10 337617892 [main] rxvt 1540 _read: read (4, 0x413200,
1024) nonblocking, sigcatchers 5    
> 00064710    1486.77212160    [1540] MsYs00000045 200 337618006 [main] rxvt 1540 peek_pipe: /dev/ptmx,
ready for read    
> 00064711    1486.77221071    [1540] MsYs00000058 100 337618121 [main] rxvt 1540
fhandler_pty_master::process_slave_output: bytes read 1    
> 00064712    1486.77229732    [1540] MsYs00000057 100 337618213 [main] rxvt 1540
fhandler_pty_master::process_slave_output: returning 1    
> 00064713    1486.77238588    [1540] MsYs00000062 10 337618300 [main] rxvt 1540 _read: 1 = read
(4</dev/ptmx>, 0x413200, 1024), bin 4096, errno 11    
> 00064714    1486.77248589    [1540] MsYs0000005A 10 337618389 [main] rxvt 1540 _read: read (4, 0x413201,
1023) nonblocking, sigcatchers 5    
> 00064715    1486.77257333    [1540] MsYs0000006D 40 337618487 [main] rxvt 1540 tty::slave_alive:
TRACE_IN: ../../../../msys/rt/src/winsup/cygwin/tty.cc, 302    
> 00064716    1486.77267809    [1540] MsYs00000067 40 337618577 [main] rxvt 1540 tty::alive: TRACE_IN:
../../../../msys/rt/src/winsup/cygwin/tty.cc, 316    
> 00064717    1486.77309379    [1540] MsYs00000063 10 337618680 [main] rxvt 1540 _read: -1 = read
(4</dev/ptmx>, 0x413201, 1023), bin 4096, errno 11    
> 
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Mingw-msys mailing list
> Mingw-msys@...
> https://lists.sourceforge.net/lists/listinfo/mingw-msys
> 

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com

Problem execing as executable from inside dlltool.exe

Hi all

Here is a rather strange problem that I ran into when attempting to build
libiconv under Msys (1.0.8) + Mingw (2.0).

% make
...
dlltool --as=as --dllname libcharset-1.dll --exclude-symbols
DllMain <at> 12,_cygwin_dll_entry <at> 12,_cygwin_noncygwin_dll_entry <at> 12,DllMainCRTStartup <at> 12,DllEntryPoint <at> 12
--def .libs/libcharset-1.dll-def --base-file .libs/libcharset-1.dll-base --output-exp .libs/libcharset-1.dll-exp
D:\MINGW\MSYS\mingw\bin\dlltool.exe: installation problem, cannot exec `as'

You can try this out for yourself by downloading:

ftp://mirrors.kernel.org/gnu/libiconv/libiconv-1.8.tar.gz

And then building with --enable-shared so that libtool tries to build a dll.

The really strange thing is that this does not seem like a problem
with the PATH. I passed a fully qualified path name as the argument
to the --as option and it still claimed that it could not exec the program.
One can "fix" this problem by removing the "--as=as" argument in each
location that it appears in the generated libtool script, but that is a bit
of a hack.

Could this have something to do with execing a 16 bit application from
inside a 32 bit one? I have no idea, I am just grasping at straws here.

cheers
Mo DeJong

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com