gnuwin32-users — Mailing list for users of GnuWin32

RE: [GnuWin32-Users] newbie question main event loop for windows ..

[Deepak K. G. N. <dk...@no...>]

hi list

First of all sorry for bothering the list by silly question.
 
I want to install the glibc on my Window-NT 4.0 (workstation) machine (i
want to use glibc's main event loop in windows). I am newbie and a bit
confused by looking at its download link. 

http://sourceforge.net/project/showfiles.php?group_id=23617&release_id=73153

What all packages i need to install on Window-NT machine to use the main
event loop function on windows
(http://developer.gnome.org/doc/API/glib/glib-the-main-event-loop.html).

Please cc the reply to me also.

Thanks in advance
Deepak.

> -----Original Message-----
> From: Kees Zeelenberg [mailto:kz...@us...]
> Sent: Saturday, October 26, 2002 2:16 PM
> To: Deepak Kumar Gupta, Noida; gnu...@li...
> Subject: Re: [GnuWin32-Users] newbie question main event loop
> g_timeout_add_full () for windows ..
> 
> 
> Looking through the sources of Glib (BTW, totally different 
> from GlibC),
> you may be able to find how the glib functions have been 
> ported to MS Windows;
> alternatively, you may ask on the gimpwin-users list.
> 
> Kees Zeelenberg
> 
> ----- Oorspronkelijk bericht -----
> Van: "Deepak Kumar Gupta, Noida" <dk...@no...>
> Aan: "Kees Zeelenberg" <kz...@us...>;
> <gnu...@li...>
> Verzonden: zaterdag 26 oktober 2002 9:33
> Onderwerp: RE: [GnuWin32-Users] newbie question main event loop
> g_timeout_add_full () for windows ..
> 
> 
> > I have already gone through the same, but the constraint is 
> , i don't want
> > to use glibc for windows.. i just want to know its 
> equivalent functions in
> > windows (in VC++) like setTimer etc..
> >
> > Actually i want to know the windows equivalent of "Main Event Loop"
> > functionality..
> > Thanks for co-operation
> > Deepak
> >
> > > -----Original Message-----
> > > From: Kees Zeelenberg [mailto:kz...@us...]
> > > Sent: Saturday, October 26, 2002 12:47 PM
> > > To: Deepak Kumar Gupta, Noida; 
> gnu...@li...
> > > Cc: Deepak Kumar Gupta, Noida
> > > Subject: Re: [GnuWin32-Users] newbie question main event loop
> > > g_timeout_add_full () for windows ..
> > >
> > >
> > > You might have a look at Glib for MS-Windows at
> > > http://www.gimp.org/~tml/gimp/win32/downloads.html
> > >
> > > Kees Zeelenberg
> > >
> > > ----- Oorspronkelijk bericht -----
> > > Van: "Deepak Kumar Gupta, Noida" <dk...@no...>
> > > Aan: <gnu...@li...>
> > > CC: "Deepak Kumar Gupta, Noida" <dk...@no...>
> > > Verzonden: zaterdag 26 oktober 2002 7:27
> > > Onderwerp: [GnuWin32-Users] newbie question main event loop
> > > g_timeout_add_full
> > > () for windows ..
> > >
> > >
> > > > Hello List,
> > > >
> > > > I want to know about the windows functions (any equivalent
> > > API in VC++)
> > > > similar to g_timeout_add_full (present in glibc) . My
> > > application (VC++)
> > > > needs to use it. Can anybody tell me, what should i do ?.
> > > >
> > > > Please cc reply to me also as i haven't subscribe the list
> > > till now..
> > > >
> > > > FYI the work of function given at following link: -
> > > >
> > > >
> > 
> http://developer.gnome.org/doc/API/2.0/glib/glib-the-main-even
t-loop.html#g-
> > timeout-add-full
> >
> >
> > g_timeout_add_full ()
> > Sets a function to be called at regular intervals, with the given
> priority.
> > The function is called repeatedly until it returns FALSE, at which point
> the
> > timeout is automatically destroyed and the function will not be called
> > again. The notify function is called when the timeout is destroyed. The
> > first call to the function will be at the end of the first interval.
> > Note that timeout functions may be delayed, due to the processing of
other
> > event sources. Thus they should not be relied on for precise timing.
After
> > each call to the timeout function, the time of the next timeout is
> > recalculated based on the current time and the given interval (it does
not
> > try to 'catch up' time lost in delays).
> >
> > Thanks in advance..
> >
> > Deepak
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ApacheCon, November 18-21 in
> > Las Vegas (supported by COMDEX), the only Apache event to be
> > fully supported by the ASF. http://www.apachecon.com
> > _______________________________________________
> > GnuWin32-Users mailing list
> > Gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuwin32-users
> >
>

Re: [GnuWin32-Users] newbie question main event loop g_timeout_add_full () for windows ..

[Tor L. <tm...@ik...>]

Kees Zeelenberg writes:
 > Looking through the sources of Glib (BTW, totally different from
 > GlibC), you may be able to find how the glib functions have been
 > ported to MS Windows; alternatively, you may ask on the
 > gimpwin-users list.

As it happens, I (who was much involved in the port GLib to Win32) am
lurking on this list...

 > > I have already gone through the same, but the constraint is , i don't want
 > > to use glibc for windows.. i just want to know its equivalent functions in
 > > windows (in VC++) like setTimer etc..

Yes, SetTimer().

 > > Actually i want to know the windows equivalent of "Main Event Loop"
 > > functionality..

If you application does "normal" Windows message handling, wouldn't
your window procedure qualify? Call SetTimer() and handle the WM_TIMER
messages.

--tml

Re: [GnuWin32-Users] newbie question main event loop g_timeout_add_full () for windows ..

[Kees Z. <kz...@us...>]

Looking through the sources of Glib (BTW, totally different from GlibC),
you may be able to find how the glib functions have been ported to MS Windows;
alternatively, you may ask on the gimpwin-users list.

Kees Zeelenberg

----- Oorspronkelijk bericht -----
Van: "Deepak Kumar Gupta, Noida" <dk...@no...>
Aan: "Kees Zeelenberg" <kz...@us...>;
<gnu...@li...>
Verzonden: zaterdag 26 oktober 2002 9:33
Onderwerp: RE: [GnuWin32-Users] newbie question main event loop
g_timeout_add_full () for windows ..


> I have already gone through the same, but the constraint is , i don't want
> to use glibc for windows.. i just want to know its equivalent functions in
> windows (in VC++) like setTimer etc..
>
> Actually i want to know the windows equivalent of "Main Event Loop"
> functionality..
> Thanks for co-operation
> Deepak
>
> > -----Original Message-----
> > From: Kees Zeelenberg [mailto:kz...@us...]
> > Sent: Saturday, October 26, 2002 12:47 PM
> > To: Deepak Kumar Gupta, Noida; gnu...@li...
> > Cc: Deepak Kumar Gupta, Noida
> > Subject: Re: [GnuWin32-Users] newbie question main event loop
> > g_timeout_add_full () for windows ..
> >
> >
> > You might have a look at Glib for MS-Windows at
> > http://www.gimp.org/~tml/gimp/win32/downloads.html
> >
> > Kees Zeelenberg
> >
> > ----- Oorspronkelijk bericht -----
> > Van: "Deepak Kumar Gupta, Noida" <dk...@no...>
> > Aan: <gnu...@li...>
> > CC: "Deepak Kumar Gupta, Noida" <dk...@no...>
> > Verzonden: zaterdag 26 oktober 2002 7:27
> > Onderwerp: [GnuWin32-Users] newbie question main event loop
> > g_timeout_add_full
> > () for windows ..
> >
> >
> > > Hello List,
> > >
> > > I want to know about the windows functions (any equivalent
> > API in VC++)
> > > similar to g_timeout_add_full (present in glibc) . My
> > application (VC++)
> > > needs to use it. Can anybody tell me, what should i do ?.
> > >
> > > Please cc reply to me also as i haven't subscribe the list
> > till now..
> > >
> > > FYI the work of function given at following link: -
> > >
> > >
> http://developer.gnome.org/doc/API/2.0/glib/glib-the-main-event-loop.html#g-
> > timeout-add-full
> >
> >
> > g_timeout_add_full ()
> > Sets a function to be called at regular intervals, with the given
> priority.
> > The function is called repeatedly until it returns FALSE, at which point
> the
> > timeout is automatically destroyed and the function will not be called
> > again. The notify function is called when the timeout is destroyed. The
> > first call to the function will be at the end of the first interval.
> > Note that timeout functions may be delayed, due to the processing of other
> > event sources. Thus they should not be relied on for precise timing. After
> > each call to the timeout function, the time of the next timeout is
> > recalculated based on the current time and the given interval (it does not
> > try to 'catch up' time lost in delays).
> >
> > Thanks in advance..
> >
> > Deepak
> >
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: ApacheCon, November 18-21 in
> > Las Vegas (supported by COMDEX), the only Apache event to be
> > fully supported by the ASF. http://www.apachecon.com
> > _______________________________________________
> > GnuWin32-Users mailing list
> > Gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuwin32-users
> >
>

RE: [GnuWin32-Users] newbie question main event loop g_timeout_ad d_full () for windows ..

[Deepak K. G. N. <dk...@no...>]

I have already gone through the same, but the constraint is , i don't want
to use glibc for windows.. i just want to know its equivalent functions in
windows (in VC++) like setTimer etc.. 

Actually i want to know the windows equivalent of "Main Event Loop"
functionality..
Thanks for co-operation
Deepak

> -----Original Message-----
> From: Kees Zeelenberg [mailto:kz...@us...]
> Sent: Saturday, October 26, 2002 12:47 PM
> To: Deepak Kumar Gupta, Noida; gnu...@li...
> Cc: Deepak Kumar Gupta, Noida
> Subject: Re: [GnuWin32-Users] newbie question main event loop
> g_timeout_add_full () for windows ..
> 
> 
> You might have a look at Glib for MS-Windows at
> http://www.gimp.org/~tml/gimp/win32/downloads.html
> 
> Kees Zeelenberg
> 
> ----- Oorspronkelijk bericht -----
> Van: "Deepak Kumar Gupta, Noida" <dk...@no...>
> Aan: <gnu...@li...>
> CC: "Deepak Kumar Gupta, Noida" <dk...@no...>
> Verzonden: zaterdag 26 oktober 2002 7:27
> Onderwerp: [GnuWin32-Users] newbie question main event loop 
> g_timeout_add_full
> () for windows ..
> 
> 
> > Hello List,
> >
> > I want to know about the windows functions (any equivalent 
> API in VC++)
> > similar to g_timeout_add_full (present in glibc) . My 
> application (VC++)
> > needs to use it. Can anybody tell me, what should i do ?.
> >
> > Please cc reply to me also as i haven't subscribe the list 
> till now..
> >
> > FYI the work of function given at following link: -
> >
> > 
http://developer.gnome.org/doc/API/2.0/glib/glib-the-main-event-loop.html#g-
> timeout-add-full
>
>
> g_timeout_add_full ()
> Sets a function to be called at regular intervals, with the given
priority.
> The function is called repeatedly until it returns FALSE, at which point
the
> timeout is automatically destroyed and the function will not be called
> again. The notify function is called when the timeout is destroyed. The
> first call to the function will be at the end of the first interval.
> Note that timeout functions may be delayed, due to the processing of other
> event sources. Thus they should not be relied on for precise timing. After
> each call to the timeout function, the time of the next timeout is
> recalculated based on the current time and the given interval (it does not
> try to 'catch up' time lost in delays).
>
> Thanks in advance..
>
> Deepak
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ApacheCon, November 18-21 in
> Las Vegas (supported by COMDEX), the only Apache event to be
> fully supported by the ASF. http://www.apachecon.com
> _______________________________________________
> GnuWin32-Users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuwin32-users
>

Re: [GnuWin32-Users] newbie question main event loop g_timeout_add_full () for windows ..

[Kees Z. <kz...@us...>]

You might have a look at Glib for MS-Windows at
http://www.gimp.org/~tml/gimp/win32/downloads.html

Kees Zeelenberg

----- Oorspronkelijk bericht -----
Van: "Deepak Kumar Gupta, Noida" <dk...@no...>
Aan: <gnu...@li...>
CC: "Deepak Kumar Gupta, Noida" <dk...@no...>
Verzonden: zaterdag 26 oktober 2002 7:27
Onderwerp: [GnuWin32-Users] newbie question main event loop g_timeout_add_full
() for windows ..


> Hello List,
>
> I want to know about the windows functions (any equivalent API in VC++)
> similar to g_timeout_add_full (present in glibc) . My application (VC++)
> needs to use it. Can anybody tell me, what should i do ?.
>
> Please cc reply to me also as i haven't subscribe the list till now..
>
> FYI the work of function given at following link: -
>
> http://developer.gnome.org/doc/API/2.0/glib/glib-the-main-event-loop.html#g-
> timeout-add-full
>
>
> g_timeout_add_full ()
> Sets a function to be called at regular intervals, with the given priority.
> The function is called repeatedly until it returns FALSE, at which point the
> timeout is automatically destroyed and the function will not be called
> again. The notify function is called when the timeout is destroyed. The
> first call to the function will be at the end of the first interval.
> Note that timeout functions may be delayed, due to the processing of other
> event sources. Thus they should not be relied on for precise timing. After
> each call to the timeout function, the time of the next timeout is
> recalculated based on the current time and the given interval (it does not
> try to 'catch up' time lost in delays).
>
> Thanks in advance..
>
> Deepak
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ApacheCon, November 18-21 in
> Las Vegas (supported by COMDEX), the only Apache event to be
> fully supported by the ASF. http://www.apachecon.com
> _______________________________________________
> GnuWin32-Users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuwin32-users
>

[GnuWin32-Users] newbie question main event loop g_timeout_add_full () for windows ..

[Deepak K. G. N. <dk...@no...>]

Hello List, 

I want to know about the windows functions (any equivalent API in VC++)
similar to g_timeout_add_full (present in glibc) . My application (VC++)
needs to use it. Can anybody tell me, what should i do ?.

Please cc reply to me also as i haven't subscribe the list till now..

FYI the work of function given at following link: -

http://developer.gnome.org/doc/API/2.0/glib/glib-the-main-event-loop.html#g-
timeout-add-full


g_timeout_add_full ()
Sets a function to be called at regular intervals, with the given priority.
The function is called repeatedly until it returns FALSE, at which point the
timeout is automatically destroyed and the function will not be called
again. The notify function is called when the timeout is destroyed. The
first call to the function will be at the end of the first interval. 
Note that timeout functions may be delayed, due to the processing of other
event sources. Thus they should not be relied on for precise timing. After
each call to the timeout function, the time of the next timeout is
recalculated based on the current time and the given interval (it does not
try to 'catch up' time lost in delays).

Thanks in advance..

Deepak 

[GnuWin32-Users] Xpm2wico 0.2.4.2

[Kees Z. <kz...@us...>]

A port of the latest xpm2wico (0.2.4.2) is available from 
http://gnuwin32.sourceforge.net/
Xpm2Wico converts an xpm image to a Windows icon.

Changes from the last release (0.2.3) on GnuWin32 are:

- don't crash on Windows when no filename is specified.
- don't display useless debugging info.
- don't die when using an invalid rgb.txt file unless necessary.
- display more informations when loading colour database in verbose mode.
- license change in the manual page;
- updated manual page;
- include optional GNU getopt to reenable Win32 compilation;
- make it possible to compile with the GNU Win32 project's Xpm lib as
  well as with Cygwin32's.
- command line options available through the getopt API;
- support for parsing X11's rgb.txt for verbatim colour names;
- misc. bugfixes;

Kees Zeelenberg

----- Oorspronkelijk bericht ----- 
Van: "Wolfgang Sourdeau" <wol...@co...>
Aan: <gnu...@li...>
Verzonden: zondag 6 oktober 2002 23:06
Onderwerp: [GnuWin32-Users] [ANNOUNCE] Xpm2wico 0.2.4.2

[GnuWin32-Users] [ANNOUNCE] Xpm2wico 0.2.4.2

[Wolfgang S. <wol...@co...>]

Hi all,


I did not found where to write the gnuwin32 project's maintainer except
this list so sorry for the inconvenience if any.

I have just release xpm2wico, which can be downloaded from
ftp://ftp.gnu.org/gnu/halifax/tools/xpm2wico-0.2.4.2.tar.gz.

This version contains some pertaining enhancements:
- X11's rgb.txt database parsing (a copy is provided with the
  distribution) for symbolic colours matching;
- GNU style command-line parsing (through the getopt and getopt_long
  API's, of which a version is provided for Win32 compilation);
- a couple of important bug fixes in the generation of icons.

A few previous versions where not compilable for Win32 and this has been
fixed recently (MinGW32's gcc being the reference compiler but it should
compile fine with Cygnus's too).

I also would like to report that the referenced web page is no longer
available. There is not replacement page either. The current official
repository for the package being the one mentioned above.


Wolfgang

Re: [GnuWin32-Users] wvWare: more and more dlls

[Kees Z. <kz...@us...>]

See the section Requirements at http://gnuwin32.sourceforge.net/packages/=
wv.htm for
the packages that Wv needs.

Kees Zeelenberg

----- Oorspronkelijk bericht -----
Van: "Carlos Garc=EDa del Monte" <cg...@wo...>
Aan: <gnu...@li...>
Verzonden: zaterdag 5 oktober 2002 20:59
Onderwerp: [GnuWin32-Users] wvWare: more and more dlls


> Hello:
> I downloaded wvWare, the binary distribution, from your site, I use
> windows 2000, when I tried to run the program, from command line, of
> course, I got first the messagebox saying it didn't found libiconv.dll.
> As I have it, but out of the path, I copyed it to the bin dir of wxWare=
,
> so it can find it, then it says it doesn't find libjpeg, I copy it
> again,
> and since it is related in many places to libpng, libxpm, libz.dll, I
> copy them too, then it says it needs freetype.dll, right, I copy it, th=
e
> libwmf.dll I download it and send to the bin, and
> now it asks for libplot.dll. I've not it, and before start to download
> more and more dlls, I would like know what's the whole set of dlls this
> program needs.
> I have not Imagemagick, and if it will still need every existing dll...
> Thank you.
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> GnuWin32-Users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuwin32-users
>

[GnuWin32-Users] wvWare: more and more dlls

[Carlos d. M. <cg...@wo...>]

Hello:
I downloaded wvWare, the binary distribution, from your site, I use
windows 2000, when I tried to run the program, from command line, of
course, I got first the messagebox saying it didn't found libiconv.dll.
As I have it, but out of the path, I copyed it to the bin dir of wxWare,
so it can find it, then it says it doesn't find libjpeg, I copy it
again,
and since it is related in many places to libpng, libxpm, libz.dll, I
copy them too, then it says it needs freetype.dll, right, I copy it, the
libwmf.dll I download it and send to the bin, and
now it asks for libplot.dll. I've not it, and before start to download
more and more dlls, I would like know what's the whole set of dlls this
program needs.
I have not Imagemagick, and if it will still need every existing dll...
Thank you.

[GnuWin32-Users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[Soren A <sor...@fa...>]

Way back on Mon, 2 Sep 2002, Bruno Haible <br...@cl...> wrote in
news:157...@ho...: 

> The mingw32 porters of libtool decided to keep the "lib" prefix - for
> reasons I can only speculate about (maybe the desire to minimize the
> changes in Makefiles or in libtool?).

I am not "one of the porters" but I know that I have a certain way of
thinking that I have developed, and it is based on how gcc works. Gcc is
going to look for a library filename "libFOO[.dll].a" if you pass it a
flag '-lFOO' in a linking step (compiler command). I believe (99% sure
this is up to date and not untrue data) that it will ALSO look for a
file named "FOO.a" if "libFOO.a" isn't found to satisfy the linking that
needs to be done. 

Sometimes when we discuss these things it isn't easy to understand that
people don't do this work in tiny little steps ... "type one line of
code, step away from the computer, have a meal, see a movie with the
family, play with the cat" ... then having had a long time to think
about it, "type another line of code, repeat something like the
above...". The point is that when i am working i am working intensely at
the greatest possible speed. The fewer extra permutations of rules I
have to remember to hold simultaneously in my overcrowded mind, the
faster I can work. 

Naming of libraries is just _exactly_ one of these things. Anybody who
just cannot *get it* can say "that's such a tiny thing, what's hard
about adapting to that" if they cannot recognize that these things are
not in isolation or impacting at some leisurely, slow pace. All sorts of
little conventions like this _add up_ to slow down a process so much
that sometimes it might not get finished at all. 

Except in special cases, i think it would be a good, friendly thing to
stick to a convention of naming libraries libWHATEVER.dll and
libWHATEVER.dll.a for its import lib. That's IMHO as a user of GNU
compiler tools. MSVC users of course have a differing perspective. 

   Regards,
      Soren A

-- 
What do Internet Mailing Lists and crowded neighborhoods have in
common? Both will either drive you out or teach you how to ignore
barking dogs.

[GnuWin32-Users] How to subscribe to Mailing List of this Newsgroup ?

[Alex V. <al...@co...>]

How to subscribe to Mailing List of this Newsgroup ?

Thanks,

   ==================
   Alex Vinokur
     mailto:al...@go...
     http://up.to/alexvn
   ==================

[GnuWin32-Users] GSL-1.2

[Przemyslaw S. <sl...@eu...>]

Hi people,

I want to ask you, how I can compile the gsl-1.2 library under Windows 98. 
I want to use it with Devcpp, which uses the Mingw-C compiler for Windows.

Thanks for help

Przemo

[Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[James M. D. <mdu...@ya...>]

--- Bruno Haible <br...@cl...> wrote:

> > The only things that were a problem were some
> > linking problems,
> 
> Strange. With the mingw-2.1 (which I got from
> http://www.cygwin.com/mirrors.html,
> *not* from http://www.mingw.org/)
> libiconv builds out of the box.
> 

I am working under DEBIAN linux using a cross compiler, on creating a
package that can be built from apt-get source/apt-src --build install. 

The changes that I needed to make were relevant to the linker and
compiler settings, and specific to the the cross compiler.

If the user has WINE installed, he can even execute the tests from
config to get the needed values, this is another part that needs
changing.

If I find some more time this week, I will post a very detailed report
on exactly what changes need to be made to compile under DEBIAn/mingw32

Mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

[Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[Earnie B. <ear...@ya...>]

Tor Lillqvist wrote:

> Bruno Haible writes:
>  > I decided for the DLL name generated by Makefile.msvc - knowing that
>  > in the Woe32 world, the prefix "lib" is uncommon.
>
>  > The mingw32 porters of libtool decided to keep the "lib" prefix - for
>  > reasons I can only speculate about (maybe the desire to minimize the
>  > changes in Makefiles or in libtool?).
>
> This is a bit unfortunate, as there now are functionally identical
> DLLs floating around under these two names. (A libiconv DLL compiled
> with either gcc or MSVC is to the best of my knowledge perfectly
> useable from both gcc- and MSVC-compiled code.)
>

That depends on C vs C++.  AFAIK all of the C exports are fully compatible
between the to environments.  However, C++ is not.  From what I see, though,
libiconv is just C source.

>
> IMHO it would be best to standardize on using either one of these
> names. I have a slight bias in favour of "iconv.dll" as that is what
> the GLib DLL has been linked to until now. But I understand that for
> others the situation might be vice versa...

I agree to the standardization but I would standardize to all other
standards and give the name of libiconv.dll.  I would ask that glib change
to be consistent with the already standard lib prefix.

>
>
> (The gettext.sourceforge.net people really shouldn't be unnecessarily
> distributing their own build of the libiconv DLL, but instead use the
> officially sanctioned mingwrep one.)

Why do you think that the mingwrep distribution (or site) is "officially
sanctioned"?  I see no reason for it to be the "officially sanctioned"
distribution.  If the MinGW site itself chose to distribute this library,
would it not then be the "officially sanctioned" MinGW distribution?  I'm
still at a loss as to why the mingwrep project exists.  Now, it's become the
"officially sanctioned" site for distribution!!

Ok, maybe I'm over reacting.  But at least explain why the distributions
need to be on a project other than MinGW?

Earnie.

[Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[Earnie B. <ear...@ya...>]

Tor Lillqvist wrote:

> Bruno Haible writes:
>  > * If you want mingw32 binaries, go to http://mingwrep.sourceforge.net/
>
> BTW, is it on purpose that these binaries use a different name for
> the DLL (libiconv.dll) than what you get if you compile with MSVC
> using the Makefile.msvc (iconv.dll)?

The libiconv.dll is more standard with shared libraries from UNIX.  I can
think of no other reason they would be different.

Earnie.

Re: [Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[Kees Z. <kz...@us...>]

----- Oorspronkelijk bericht -----
Van: "Bruno Haible" <br...@cl...>
Aan: "James Michael DuPont" <mdu...@ya...>
CC: "stefan" <st...@lk...>; <gnu...@li...>; <ko...@us...>; <dia...@gn...>;
<gim...@ya...>; <Min...@li...>
Verzonden: maandag 2 september 2002 18:33
Onderwerp: [Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed
packaging of libiconv (very boring)


> James Michael DuPont writes:
> > > I think the confusion would be less if the
> > > http://gnuwin32.sourceforge.net/ page would state clearly which
> > > environment/compiler they use: mingw32 or pw32 or cygwin or msvc.
> > Well, you do have to click a few times to find it,
> > http://gnuwin32.sourceforge.net/compile.html tells you that mingw is
> > needed.
>
> Then there is competition between between this site and
> http://mingwrep.sourceforge.net/, and it would be best if these two
> projects described how they differ, and whether packages from one site
> are interoperable with packages from the other site.
>
The differences between Mingwrep and Gnuwin32 are, as far as I can see:
- Gnuwin32 always provides the source (which usually is required by the license of
   the original package) with any changes from the original  source in the form of a diff.
- Gnuwin32 always provides the documentation in a 'compiled' form, i.e.
   as PDF, HTML, PS, DVI and HLP.
- Gnuwin32 provides import libraries for MSVC and BCC wherever possible.
In general static and import libraries from Gnuwin32 should be interoperable with
libraries from Mingwrep, although the options with which the library files have been
compiled might differ (in particular, most libraries, and binaries, from Gnuwin32 have
been compiled without debug option).

Kees Zeelenberg

Re: [Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[Kees Z. <kz...@us...>]

Gnuwin32 usually names the dll after the name of the package. So
for the libiconv package the dll is called libiconv.dll, and for
the barcode package the dll is called barcode.dll. But this usage is just
a matter of taste, not of principle, and it has not been always followed.

Kees Zeelenberg

----- Oorspronkelijk bericht -----
Van: "Bruno Haible" <br...@cl...>
Aan: "Tor Lillqvist" <tm...@ik...>
CC: "stefan" <st...@lk...>; <gnu...@li...>; <ko...@us...>; <dia...@gn...>;
<gim...@ya...>; <Min...@li...>
Verzonden: maandag 2 september 2002 21:37
Onderwerp: [Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed
packaging of libiconv (very boring)


> Tor Lillqvist writes:
> >  > * If you want mingw32 binaries, go to http://mingwrep.sourceforge.net/
> >
> > BTW, is it on purpose that these binaries use a different name for
> > the DLL (libiconv.dll) than what you get if you compile with MSVC
> > using the Makefile.msvc (iconv.dll)?
>
> Apparently so.
>
> I decided for the DLL name generated by Makefile.msvc - knowing that
> in the Woe32 world, the prefix "lib" is uncommon.
>
> The mingw32 porters of libtool decided to keep the "lib" prefix - for
> reasons I can only speculate about (maybe the desire to minimize the
> changes in Makefiles or in libtool?).
>
> Bruno
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: OSDN - Tired of that same old
> cell phone?  Get a new here for FREE!
> https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390
> _______________________________________________
> Gnuwin32-users mailing list
> Gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuwin32-users
>

[Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[Tor L. <tm...@ik...>]

Bruno Haible writes:
 > I decided for the DLL name generated by Makefile.msvc - knowing that
 > in the Woe32 world, the prefix "lib" is uncommon.

 > The mingw32 porters of libtool decided to keep the "lib" prefix - for
 > reasons I can only speculate about (maybe the desire to minimize the
 > changes in Makefiles or in libtool?).

This is a bit unfortunate, as there now are functionally identical
DLLs floating around under these two names. (A libiconv DLL compiled
with either gcc or MSVC is to the best of my knowledge perfectly
useable from both gcc- and MSVC-compiled code.)

IMHO it would be best to standardize on using either one of these
names. I have a slight bias in favour of "iconv.dll" as that is what
the GLib DLL has been linked to until now. But I understand that for
others the situation might be vice versa...

(The gettext.sourceforge.net people really shouldn't be unnecessarily
distributing their own build of the libiconv DLL, but instead use the
officially sanctioned mingwrep one.)

--tml

[Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[Bruno H. <br...@cl...>]

Tor Lillqvist writes:
>  > * If you want mingw32 binaries, go to http://mingwrep.sourceforge.net/
> 
> BTW, is it on purpose that these binaries use a different name for
> the DLL (libiconv.dll) than what you get if you compile with MSVC
> using the Makefile.msvc (iconv.dll)?

Apparently so.

I decided for the DLL name generated by Makefile.msvc - knowing that
in the Woe32 world, the prefix "lib" is uncommon.

The mingw32 porters of libtool decided to keep the "lib" prefix - for
reasons I can only speculate about (maybe the desire to minimize the
changes in Makefiles or in libtool?).

Bruno

[Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[Earnie B. <ear...@ya...>]

Bruno Haible wrote:

> Strange. With the mingw-2.1 (which I got from
> http://www.cygwin.com/mirrors.html,
> *not* from http://www.mingw.org/)
> libiconv builds out of the box.
>

Same package loaded by the same maintainer to two different distribution
site.  The difference, and this in itself should cause no difference, I
choose to build the Cygwin release with Cygwin's gcc and the MinGW release
with the MinGW gcc.

Earnie.

[Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[Tor L. <tm...@ik...>]

Bruno Haible writes:
 > * If you want mingw32 binaries, go to http://mingwrep.sourceforge.net/

BTW, is it on purpose that these binaries use a different name for
the DLL (libiconv.dll) than what you get if you compile with MSVC
using the Makefile.msvc (iconv.dll)?

--tml

[Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[Bruno H. <br...@cl...>]

James Michael DuPont writes:
> > I think the confusion would be less if the
> > http://gnuwin32.sourceforge.net/ page would state clearly which
> > environment/compiler they use: mingw32 or pw32 or cygwin or msvc.
> Well, you do have to click a few times to find it,
> http://gnuwin32.sourceforge.net/compile.html tells you that mingw is
> needed.

Then there is competition between between this site and
http://mingwrep.sourceforge.net/, and it would be best if these two
projects described how they differ, and whether packages from one site
are interoperable with packages from the other site.

> > * If you want pw32 binaries, go to http://pw32.sourceforge.net/
> Do you know where to find libiconv there?

No I'm not aware of a port of libiconv to pw32.

> The only things that were a problem were some
> linking problems,

Strange. With the mingw-2.1 (which I got from
http://www.cygwin.com/mirrors.html,
*not* from http://www.mingw.org/)
libiconv builds out of the box.

> But on the webpage here :
> http://www.gnu.org/directory/libiconv.html
> It states : "This is not a GNU package."
> 
> (Note that it (Broken) links to here which is not here:
> ftp://ftp.ilog.fr/pub/Users/haible/gnu/libiconv-1.8.tar.gz

Thanks for reporting this; will be fixed.

Bruno

[Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[James M. D. <mdu...@ya...>]

Bruno,

Thank you for pointing out my mistakes, you have shed some light on
this whole issue. 

I hope that my asking questions have helped in some way to bring all
these questions to light, even if I was wrong on my conclusions.

--- Bruno Haible <br...@cl...> wrote:
> James Michael DuPont writes:
> 
> > First of all I am talking about a mingw32 under debian, and second
> of
> > all, please excuse that I overlooked your particular port, because
> > there is no clear guidelines for the user as to which of the MANY
> ports
> > he should use. 
> 
> * If you want to build from source, start out at the package's
>   homepage, as listed on freshmeat.net.
> 
> * If you want cygwin binaries, go to http://www.cygwin.com/ and
>   http://www.cygwin.com/download.html
> 
> * If you want mingw32 binaries, go to
> http://mingwrep.sourceforge.net/
And this is the official port? So http://gnuwin32.sourceforge.net/ and
it are in competition?

 
> * If you want pw32 binaries, go to http://pw32.sourceforge.net/
Do you know where to find libiconv there?

 
> I think the confusion would be less if the
> http://gnuwin32.sourceforge.net/ page would state clearly which
> environment/compiler they use: mingw32 or pw32 or cygwin or msvc.
Well, you do have to click a few times to find it,
http://gnuwin32.sourceforge.net/compile.html tells you that mingw is
needed.

> Your platform ("mingw32 under debian") appears to be new. With each
> new platform or set of packaging rules you start from scratch.

I will do just that. The only things that were a problem were some
linking problems, I will be posting very detailed patches to you on
anything I find.
 
> > lets look for iconv :
> > http://sourceforge.net/projects/libiconv/  -- This is from Haible
> 
> This is the CVS repository for libiconv.
That is what I will be using.

> > http://savannah.gnu.org/projects/libiconv  -- Oh another one!
> 
> This is the CVS repository for libiconv's homepage.
Ahhh.... I was to quick to shoot!
Sorry. :)

> 
> > http://www.gnu.org/software/libiconv/      -- The GNU Package
> 
> This is libiconv's homepage.

OK, well it looks like every other page (including the gnu software
directory) is slightly off. 

> 
> Earnie Boyd writes:
> > The real libiconv would be the one who owns it, the FSF.  One of
> the
> > problems with these smaller packages is the lack of CVS support. 
> If
> > the official maintainer used CVS then a branch could be set and all
> > of the above porters would have contributed to the same port.
> 
> All wrong. libiconv is maintained in a CVS, and the lack of CVS
> branches for cygwin/mingw32/etc. is because:
> 
>   - It compiles out of the box on cygwin,
>   - It compiles out of the box for mingw32, except for a one-liner
>     patch,
>   - It compiles out of the box for msvc, using the included
>     Makefile.msvc.

This is fine, I noticed that you just updated cvs with the mingw32
stuff. I will be using your cvs for compilation and writing to all the
people who distribute binaries to update thier links to point at your
page. 

You must admit however, 
that for a complete outsider, it is very confusing!
 
> James Michael DuPont writes:
> > I found out that FSF does not own the libiconv
> 
> Wrong. The FSF does own libiconv. Look at the copyright notices.

I am sorry about this misunderstanding, 
I was not looking deep enought, trying to go on superficial
information. 

Even in my discussion with the FSF, they did not know offhand that
libiconv was thier own copyright.

"Copyright (C) 1999-2001 Free Software Foundation, Inc.
   This file is part of the GNU LIBICONV Library."

But on the webpage here :
http://www.gnu.org/directory/libiconv.html
It states : "This is not a GNU package."

(Note that it (Broken) links to here which is not here:
ftp://ftp.ilog.fr/pub/Users/haible/gnu/libiconv-1.8.tar.gz

> 
> > Bruno Haible has THREE! different CVS controls of the sources, 
> > two on sourceforge (libiconv,clisp), one on savannah. And none on
> the
> > GNU CVS.
> 
> Wrong again. Take a look at the contents of these CVS repositories.
> Only one of them contains the maintained sources of libiconv.
OK, it is this one :
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/libiconv/libiconv/


Thanks again for you time, you have cleared up many of my questions.

mike

=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do You Yahoo!?
Yahoo! Finance - Get real-time stock quotes
http://finance.yahoo.com

[Gnuwin32-users] Re: Will the real libiconv please stand up! Was : Re: [Mingw-users] baby steps, an half-finshed packaging of libiconv (very boring)

[Bruno H. <br...@cl...>]

James Michael DuPont writes:

> First of all I am talking about a mingw32 under debian, and second of
> all, please excuse that I overlooked your particular port, because
> there is no clear guidelines for the user as to which of the MANY ports
> he should use. 

* If you want to build from source, start out at the package's
  homepage, as listed on freshmeat.net.

* If you want cygwin binaries, go to http://www.cygwin.com/ and
  http://www.cygwin.com/download.html

* If you want mingw32 binaries, go to http://mingwrep.sourceforge.net/

* If you want pw32 binaries, go to http://pw32.sourceforge.net/

I think the confusion would be less if the
http://gnuwin32.sourceforge.net/ page would state clearly which
environment/compiler they use: mingw32 or pw32 or cygwin or msvc.

Your platform ("mingw32 under debian") appears to be new. With each
new platform or set of packaging rules you start from scratch.


> lets look for iconv :
> http://sourceforge.net/projects/libiconv/  -- This is from Haible

This is the CVS repository for libiconv.

> http://savannah.gnu.org/projects/libiconv  -- Oh another one!

This is the CVS repository for libiconv's homepage.

> http://www.gnu.org/software/libiconv/      -- The GNU Package

This is libiconv's homepage.

Earnie Boyd writes:
> The real libiconv would be the one who owns it, the FSF.  One of the
> problems with these smaller packages is the lack of CVS support.  If
> the official maintainer used CVS then a branch could be set and all
> of the above porters would have contributed to the same port.

All wrong. libiconv is maintained in a CVS, and the lack of CVS
branches for cygwin/mingw32/etc. is because:

  - It compiles out of the box on cygwin,
  - It compiles out of the box for mingw32, except for a one-liner
    patch,
  - It compiles out of the box for msvc, using the included
    Makefile.msvc.

James Michael DuPont writes:
> I found out that FSF does not own the libiconv

Wrong. The FSF does own libiconv. Look at the copyright notices.

> Bruno Haible has THREE! different CVS controls of the sources, 
> two on sourceforge (libiconv,clisp), one on savannah. And none on the
> GNU CVS.

Wrong again. Take a look at the contents of these CVS repositories.
Only one of them contains the maintained sources of libiconv.

Bruno