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

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3551688
By: jhihn1

How do I do that?


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

On 2006-1-31 17:45 UTC, az...@co... wrote:
> I am using the latest release of msys.  CVS works from within the
> windows shell.  The WinCVS gui also works.  When i try to use it
> from msys it just hangs forever, until I hit ctl-c.
>
> I have tried using CVSROOT and setting it explicitly.

Just to rule out some easy things, try the following in MSYS:

export CVS_RSH="ssh"
export CVSROOT=":pserver:ano...@cv...:/sources/lmi"
cvs history -a -x T -D 20060128 lmi

Do you get at least two records back?

I am using the latest release of msys.  CVS works from within the windows shell.  The WinCVS gui also works.  When i try to use it from msys it just hangs forever, until I hit ctl-c.

I have tried using CVSROOT and setting it explicitly. 

Thanks for any advice/help

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3550320
By: keithmarshall

Hmm.  Perhaps updating the version is *not* the solution.  Like the OP, I'm
using MinGW gcc-3.2.3 (mingw-special-20030504-1), but with msys-1.0.9, and I
cannot reproduce the problem.  I've even tried emulating the OP's share and
fstab setups, indentically as indicated by `msysinfo all', (structurally, but
with directory and share name changes adapted to my own environment); I still
cannot reproduce the problem.

Regards,
Keith.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3550315
By: earnie

> So I agree that, because of the potential 
> for end-user fubar, the 
> msys-dependent ltdl DLL and the msysDTK-provided 
> libtool should go away, to be replaced by
> a non-msys-dependent libtool/libltdl DLL (except 
> just MAYBE in your 
> own personal dev env, Earnie, if you need msysltdl 
> for m4-2.0 or other msys-dependent tools).

Yes of course.  I have /etc/profile setup so that when ``uname -s'' indicates
an MSYS environment instead of a MINGW32 environment that it puts the msys specific
binary paths first in PATH.  Otherwise the MinGW binary paths are first in PATH.

I can enter into an MSYS environment by simply typing ``MSYSTEM=MSYS start
/msys''.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3550293
By: earnie

I'm using gcc version 3.4.2 (mingw-special) and don't have a problem.

You're using gcc version 3.2.3 (mingw special 20030504-1) and do have a
problem.

Solution, upgrade your version.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Hello everyone!


We are currently moving our projects to Autotools (and will release them
as LGPL once it's done - GXL anyone? Yet I doubt it ;)) and we plan to
support Linux, Darwin and Win32 using MinGW/MSys.

I'd like to say upfront: using static libs I'd be done by now! :-)

So of course I have some questions regarding libtool/shared libs...

After a lot of experimenting and reading up I can come up with the
following:

*) building shared libs on Linux is the easiest; libtool is doing a
fantastic job
*) close second is Darwin
*) a pita is Win32

For every lib I build I at first only got the static version, since I
had not set "-no-undefined" in libfoo_la_LDFLAGS; but doing so (and
that's my question actually) I get unresolved symbols on depended libs!

To cure that I need to add them to libfoo_la_LIBADD, no? And are there
problems known if doing so on Linux and Darwin, too, can cause trouble?

I'd like to keep my Makefile.am's as platform agnostic as possible...

Any comment is highly appreciated!


regards,
Florian Schricker


-- 
do() || do_not(); // try();

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3549720
By: cwilso11

> Actually if the DLL were to be used for MinGW 
> native it wouldn't work since that build of
> the dll is dependent on the msys runtime.

Well, at that level it all depends on which -L path is specified.  That is,
the import library in /lib would cause a dependency on msysltdl-3.dll, while
the import library in /mingw/lib (or wherever the "native" libltdl/libtool is
installed) would cause a dependency on libltdl-3.dll.  Of course, making sure
that you call the "right" libtool and that it self-configures such that your
autotool-generated Makefile has the "right" -L path, when there are two different
versions on the same machine is, err, prone to error.

So I agree that, because of the potential for end-user fubar, the msys-dependent
ltdl DLL and the msysDTK-provided libtool should go away, to be replaced by
a non-msys-dependent libtool/libltdl DLL (except just MAYBE in your own personal
dev env, Earnie, if you need msysltdl for m4-2.0 or other msys-dependent tools).



______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3549527
By: felix14

It's listed under windows as an NTFS drive on an NT server.  I can copy to and
from directories on the shared drive when they're mounted in MSYS.  Only gcc
is giving me problems.


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3549508
By: earnie

What type of device is your share drive?  If it is not Fat32 or NTFS it is not
likely to work.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3549418
By: felix14

Hi.  The problem only seems to occur on when I try and mount a directory from
a network-mounted drive.  Mounting works fine with local hard disk directories.
MSYS is in a separate directory from MinGW, with a mount option to link them.
I can compile and run programs with no difficulties as long as they reside on
the local hard drive.  The output of gcc with the -v switch is:

$ gcc hello.c -o hello.exe -v
Using built-in specs.
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as
--host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls
--enable-languages=c++,f77,objc --disable-win32-registry --disable-shared
--enable-sjlj-exceptions
Thread model: win32
gcc version 3.2.3 (mingw special 20030504-1)
 cc1 -lang-c -v -iprefix C:\progra~1\EGCS\lib\gcc-lib\mingw32/3.2.3/ -D__GNUC__=3
-D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=3 -D__GXX_ABI_VERSION=102 -D_WIN32
-D__WIN32 -D__WIN32__ -DWIN32 -D__MINGW32__ -D__MSVCRT__ -DWINNT -D_X86_=1 -D_WIN32
-D__WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__ -D__MSVCRT__ -D__WINNT__ -D_X86_=1
-D__WIN32 -D__WINNT -Asystem=winnt -D__NO_INLINE__ -D__STDC_HOSTED__=1 -Acpu=i386
-Amachine=i386 -Di386 -D__i386 -D__i386__ -D__tune_i586__ -D__tune_pentium__
-D__stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__))
-D__fastcall=__attribute__((__fastcall__)) -D_stdcall=__attribute__((__stdcall__))
-D_cdecl=__attribute__((__cdecl__)) -D_fastcall=__attribute__((__fastcall__))
-D__declspec(x)=__attribute__((x)) hello.c -quiet -dumpbase hello.c -version
-o C:/TEMP/ccEhaaaa.s
gcc.exe: installation problem, cannot exec `cc1': No such file or directory

msysinfo all gives:

$ msysinfo all
msysinfo-1.3: Send this to the MSYS support list:

MSYS 1.0.10(0.46/3/2) 2004-03-15 07:17 i686 unknown; targ=MINGW32
GNU bash, version 2.04.0(1)-release (i686-pc-msys); ENV=.profile
GNU Make version 3.79.1,Built for i686-pc-msys; MAKE_MODE=unix
gcc.exe (GCC) 3.2.3 (mingw special 20030504-1); targ=MINGW32
GNU ld version 2.13.90 20030111
   789320 Tue Mar 16 13:32:49 2004 /bin/msys-1.0.dll
   135680 Tue Mar 16 13:32:48 2004 /bin/make.exe
    82432 Sun May 04 22:38:20 2003 /mingw/bin/gcc.exe
   566272 Sun Jan 12 05:42:48 2003 /mingw/bin/ld.exe
HOME=/home/ajc189
Sysname=MINGW32_NT-5.1  OSTYPE=msys  TERM=msys
PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WIN
DOWS:/c/WINDOWS/System32/Wbem:/o/miktex/bin:/c/progra~1/egcs/bin
:/c/progra~1/pscad401/bin/ffilter:/c/MODELTECH/win32://elec.cant
erbury.ac.nz/root/commonapp/CADENCE/SPB_15.2/tools/bin://elec.ca
nterbury.ac.nz/root/commonapp/CADENCE/SPB_15.2/tools/specctra/bi
n://elec.canterbury.ac.nz/root/commonapp/CADENCE/SPB_15.2/tools/
pcb/bin://elec.canterbury.ac.nz/root/commonapp/CADENCE/SPB_15.2/
tools/fet/bin://elec.canterbury.ac.nz/root/commonapp/CADENCE/SPB
_15.2/tools/Capture:%//elec.canterbury.ac.nz/root/commonapp/CADE
NCE/SPB_15.2%/tools/bin:%//elec.canterbury.ac.nz/root/commonapp/
CADENCE/SPB_15.2%/tools/specctra/bin:%//elec.canterbury.ac.nz/ro
ot/commonapp/CADENCE/SPB_15.2%/tools/pcb/bin:%//elec.canterbury.
ac.nz/root/commonapp/CADENCE/SPB_15.2%/tools/fet/bin:%//elec.can
terbury.ac.nz/root/commonapp/CADENCE/SPB_15.2%/tools/Capture
$ ls -tx /home/ajc189/tempj
hello.c

bbfe534c85236d94683f3461829ef10b */bin/msys-1.0.dll
0e7941487ca8156a25b46b0b8f9a8bd9 */bin/make.exe
aad05e77b37da603d3097824834fdfc8 */mingw/bin/gcc.exe
2a5cf34e94bb25814907a8111fd937a7 */mingw/bin/ld.exe

In /etc/fstab:
c:/MinGW /mingw
c:/holdit /home/ajc189/temp
i:/src/ /home/ajc189/tempi
j:/documents/hold/temp /home/ajc189/tempj

In /etc/profile:
  export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH"
  export PATH=".:/usr/local/bin:/bin:/mingw/bin:$PATH"
export HOME LOGNAME MSYSTEM HISTFILE
export MAKE_MODE=unix
export PS1='\[\033]0;$MSYSTEM:\w\007

%%% MSYS dll major: 1000
%%% MSYS dll minor: 10
%%% MSYS dll epoch: 19
%%% MSYS dll bad signal mask: 19005
%%% MSYS dll old termios: 5
%%% MSYS dll malloc env: 28
%%% MSYS api major: 0
%%% MSYS api minor: 46
%%% MSYS shared data: 3
%%% MSYS dll identifier: cygwin1
%%% MSYS mount registry: 2
%%% MSYS cygnus registry name: msys
%%% MSYS cygwin registry name: 1.0
%%% MSYS program options name: Program Options
%%% MSYS cygwin mount registry name: mounts v2
%%% MSYS cygdrive flags: cygdrive flags
%%% MSYS cygdrive prefix: cygdrive prefix
%%% MSYS cygdrive default prefix: 
%%% MSYS build date: Mon Mar 15 07:17:24 EST 2004
%%% MSYS shared id: cygwin1S3

!::='::\'
!C:='C:\msys\1.0\bin'
ALLUSERSPROFILE='C:\WINDOWS\profiles\All Users'
APPDATA='\\coanda\ajc189$\application data'
AWR_LICENSE_FILE='C:\WINDOWS\AWR.LIC'
BASH=/usr/bin/sh
BASH_VERSINFO=([0]="2" [1]="04" [2]="0" [3]="1" [4]="release" 
[5]="i686-pc-msys")
BASH_VERSION='2.04.0(1)-release'
BGCOLOR=LightYellow
CDSROOT='\\elec.canterbury.ac.nz\root\commonapp\CADENCE\SPB_15.2
'
CDS_LIC_FILE=5280@ZIPSERVER
COLORFGBG='default;default'
COLORTERM=rxvt
COMMONPROGRAMFILES='C:\Program Files\Common Files'
COMPUTERNAME=ELECPG74
COMSPEC='C:\WINDOWS\system32\cmd.exe'
CONCEPT_INST_DIR='\\elec.canterbury.ac.nz\root\commonapp\CADENCE
\SPB_15.2'
DIRSTACK=()
DISPLAY=:0
EUID=500
FGCOLOR=Navy
FP_NO_HOST_CHECK=NO
FULLNAME='Antony James Culliford'
GCC_EXEC_PREFIX='C:\progra~1\EGCS\lib\gcc-lib\'
GROUPS=()
HISTFILE=/home/ajc189/.bash_history
HOME=/home/ajc189
HOMEDRIVE='\\'
HOMEPATH='coanda\ajc189$'
HOMESHARE='\\coanda\ajc189$'
HOSTNAME=ELECPG74
HOSTTYPE=i686
IFS='   
'
ITHOME='\\CANTWS1\USERS\ajc189'
LM_LICENSE_FILE=1717@ZIPSERVER
LOCATION=staff
LOGNAME=ajc189
LOGONSERVER='\\ENGCAD3'
MACHTYPE=i686-pc-msys
MAKE_MODE=unix
MINGW32BGCOLOR=LightYellow
MINGW32FGCOLOR=Navy
MONTH=January
MSYSBGCOLOR=White
MSYSFGCOLOR=Black
MSYSTEM=MINGW32
NUMBER_OF_PROCESSORS=2
OPTERR=1
OPTIND=1
OS=Windows_NT
OSTYPE=msys
PATH=.:/usr/local/bin:/mingw/bin:/bin:/c/WINDOWS/system32:/c/WIN
DOWS:/c/WINDOWS/System32/Wbem:/o/miktex/bin:/c/progra~1/egcs/bin
:/c/progra~1/pscad401/bin/ffilter:/c/MODELTECH/win32://elec.cant
erbury.ac.nz/root/commonapp/CADENCE/SPB_15.2/tools/bin://elec.ca
nterbury.ac.nz/root/commonapp/CADENCE/SPB_15.2/tools/specctra/bi
n://elec.canterbury.ac.nz/root/commonapp/CADENCE/SPB_15.2/tools/
pcb/bin://elec.canterbury.ac.nz/root/commonapp/CADENCE/SPB_15.2/
tools/fet/bin://elec.canterbury.ac.nz/root/commonapp/CADENCE/SPB
_15.2/tools/Capture:%//elec.canterbury.ac.nz/root/commonapp/CADE
NCE/SPB_15.2%/tools/bin:%//elec.canterbury.ac.nz/root/commonapp/
CADENCE/SPB_15.2%/tools/specctra/bin:%//elec.canterbury.ac.nz/ro
ot/commonapp/CADENCE/SPB_15.2%/tools/pcb/bin:%//elec.canterbury.
ac.nz/root/commonapp/CADENCE/SPB_15.2%/tools/fet/bin:%//elec.can
terbury.ac.nz/root/commonapp/CADENCE/SPB_15.2%/tools/Capture
PATHEXT='.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PIPESTATUS=([0]="0")
PPID=3304
PROCESSOR_ARCHITECTURE=x86
PROCESSOR_IDENTIFIER='x86 Family 15 Model 2 Stepping 9, 
GenuineIntel'
PROCESSOR_LEVEL=15
PROCESSOR_REVISION=0209
PROGRAMFILES='C:\Program Files'
PROMPT='$P$G'
PS4='+ '
PWD=/home/ajc189/tempj
SESSIONNAME=Console
SHELL=/bin/sh
SHELLOPTS=braceexpand:hashall:interactive-comments
SHLVL=2
SYSTEMDRIVE=C:
SYSTEMROOT='C:\WINDOWS'
TANNERHOST=132.181.51.108
TANNERHOST2=local
TEMP=/tmp
TERM=msys
TMP=/tmp
UID=500
USERDNSDOMAIN=ENG.CANTERBURY.AC.NZ
USERDOMAIN=ENG
USERNAME=ajc189
USERPROFILE='C:\WINDOWS\profiles\ajc189'
WINDIR='C:\WINDOWS'
WINDOWID=167838920
_=echo

$ msysinfo all >msysinfo.txt   will save this to a file

Thanks for the help.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Shriramana Sharma wrote:
>> You need to quote the font name in the RXVT start up command, e.g.:
>>   ``... -fn 'DejaVu Sans Mono'-16 ...''
>>
>> However, you may find the effect is disappointing;  for me, this
>> results in excessive and irregular glyph spacing!
>
> Yes, I found this happening too. Is this because DejaVu is Unicode
> and Courier is ANSI?

That seems a likely explanation.

[OT] I notice you are
> Running SUSE Linux 10.0 with KDE 3.5

I just upgraded my old Mandrake 8.2 box to SuSE 10.0, this weekend.
On shutting down, I observed a SIGSEGV from the Kicker -- have you
ever had any such problem?

Regards,
Keith.

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3548475
By: earnie

Add the -v switch to gcc and give us the output.  Also what is the output of
``msysinfo all''?

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3548466
By: keithmarshall

How did you create your "mounted" directory?

I did this:--
$ mkdir /d/opt
$ echo D:/opt /opt >> /etc/fstab
$ mv ~/hello.c /opt
$ ls /d/opt
hello.c
$ gcc -o hello /opt/hello.c
$ ./hello
Hello World!

I cannot reproduce your problem.  Do you have a proper "mount" definition for
/mingw in your /etc/fstab?  It should be something like:--
D:/mingw  /mingw

Make sure that your MinGW and MSYS installations do *not* share a common root
directory.

Regards,
Keith.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Monday, 30 January 2006 16:37 samaye, Keith MARSHALL alekhiit:

> You need to quote the font name in the RXVT start up command, e.g.:
> =A0 ``... -fn 'DejaVu Sans Mono'-16 ...''
>
> However, you may find the effect is disappointing; =A0for me, this
> results in excessive and irregular glyph spacing!

Yes, I found this happening too. Is this because DejaVu is Unicode and Cour=
ier=20
is ANSI?

Thanks for the make/mingwmake explanation.

=2D-=20

Shriramana Sharma  http://samvit.org
Running SUSE Linux 10.0 with KDE 3.5

Shriramana Sharma wrote:
> I would like to change the font used by MSys from Courier-12 to
> something else. I think the start rxvt command is where to do it.
> But the font I want to use has spaces in its name
>  - DejaVu Sans Mono.
> How do I use this?

You need to quote the font name in the RXVT start up command, e.g.:
  ``... -fn 'DejaVu Sans Mono'-16 ...''

However, you may find the effect is disappointing;  for me, this
results in excessive and irregular glyph spacing!

BTW, you are advised against customising msys.bat in this manner;
if you ever reinstall MSYS, your customisation will be overwritten.
However, there is currently no other way to achieve the customisation
you desire, without modifying msys.bat;  provided you remember this
potential volatility, feel free to experiment.

> BTW I would like to know why the MSys post-install says:
> "Oh joy, you do not have C:/MinGW/bin/make.exe. Keep it that way."

MinGW provides a Win32 native build of GNU make, nominally identified
as `mingw32-make.exe'.  MSYS also provides its own version of GNU make,
which offers more reliable operation, but can only be used in the MSYS
environment; this version is named `make.exe'.

The comment in the post install is a caution, lest you be tempted to
rename `mingw32-make.exe' as `make.exe';  in MSYS, you want to use the
MSYS version, and keeping the unambiguously different names avoids any
possibility of using the wrong one.

Regards,
Keith.

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3547851
By: felix14

Hi

I've just recently installed MSYS/MinGW.  I can compile and run a "Hello World"
type program when the source is in my home directory.  When the source is in
a mounted directory however, gcc exits with the following error:

gcc.exe: installation problem, cannot exec `cc1': No such file or directory

The mount shows up correctly in MSYS, and I can copy files from it with
no difficulties.

Does anyone have any ideas what the problem might be?

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Hello. This is my first post.

I would like to change the font used by MSys from Courier-12 to
something else. I think the start rxvt command is where to do it. But
the font I want to use has spaces in its name - DejaVu Sans Mono. How
do I use this?

BTW I would like to know why the MSys post-install says:

"Oh joy, you do not have C:/MinGW/bin/make.exe. Keep it that way."

Thank you.

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3546953
By: earnie

Actually if the DLL were to be used for MinGW native it wouldn't work since
that build of the dll is dependent on the msys runtime.

It would be better to replace the dll with a windows version.  I'll take another
look sometime in May.

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

  I already understood I eat I function autoconf, automake and libtool but exists some way of the o to compile a DLL in the place of it to have the name libTest.dll it has the Test.dll name?
   
  Thanks.


		
---------------------------------
 Yahoo! doce lar. Faça do Yahoo! sua homepage.

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3545949
By: cwilso11

That's fine for autoconf and automake, but not for libtool.  The libtool provided
in the msysDTK has a shared library for libltdl: this msysltdl-3.dll relies
on msys, and uses msys-supplied dlopen().  It does not use LoadLibrary directly.

This is probably what you want, IF you're building an MSYS (not native) tool
that uses libltdl.  E.g. an MSYS version of m4-2.0.

The libtool-1.5 mingwPORT provides a libltdl shared library libltdl-3.dll which
uses LoadLibrary() directly, and does not use msys at all.

THIS is what you want if you're building native apps that use ltdl.

I guess if you're sure that you'll never need and msys-ified version of the
libltdl, then moving all three autotools to mingwPORTS is okay.


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3545904
By: earnie

Jason,

You need to specify the winsock library.

http://www.google.com/search?hl=en&q=win32+gethostbyname&btnG=Google+Search

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3545900
By: earnie

Hi Chuck,

More accidental than intentional.  Lack of time to do it correctly and uploaded
to quiet the list.

The autotools in the msysDTK are scheduled to be removed and the mingwPORT versions
promoted as the standard method of installing them.

Earnie

______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3545734
By: cwilso11

Is built static-only, but it replaces libtool-1.4e in the msysDTK-1.0.1 which
includes both dynamic (/lib/msysltdl-3.dll + /lib/libltdl.dll.a) and static
(/lib/libltdl.a) versions.

Is this intentional?


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575

Read and respond to this message at: 
https://sourceforge.net/forum/message.php?msg_id=3545566
By: jhihn1

I am using msys-1.0.10, mingw with gcc 3.4.2 and I tried to run an application's
configure script. It failed on the networking with undefined references to:
connect, listen, bind, accept, send, sendto, sendmsg and gethostbyname.

What do I need to install or pecify to get this to work?

Thanks!
I just installed all of this today so i don't knwo what could be wrong.


______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit: 
https://sourceforge.net/forum/unmonitor.php?forum_id=338575