GLib co-exiting dependency problem, kinda my fault...

classic Classic list List threaded Threaded
14 messages Options
Tal
Reply | Threaded
Open this post in threaded view
|

GLib co-exiting dependency problem, kinda my fault...

Tal
I have install before 2~3 months MinGW and because I didn't know how to compile&install GLib from source, I took the easy way and download© the files from this address(the dev):
http://www.gtk.org/download-windows.html
Everything went very well, but I have decide to upgrade GLib from 2.26.1 to 2.28.7 by installing from the source(because now I know better MSYS).
I haven't removed the binaries I've download back then(2.26.1), because I thought the new GLib will override the files.
Even know it went well, when I tried to upgrade gdk-pixbuf(which the older version was based on win32 dev files too), to gdk-pixbuf-2.22.1, without removing gdk-pixbuf binaries(it should override them), I'm getting this error while configuring:

...
checking pkg-config is at least version 0.16... yes
checking for GLIB - version >= 2.25.15...
*** 'pkg-config --modversion glib-2.0' returned 2.28.7, but GLIB (2.26.1)
*** was found! If pkg-config was correct, then it is best
*** to remove the old version of GLib. You may also be able to fix the error
*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing
*** /etc/ld.so.conf. Make sure you have run ldconfig if that is
*** required on your system.
*** If pkg-config was wrong, set the environment variable PKG_CONFIG_PATH
*** to point to the correct configuration files
no
configure: error:
*** GLIB 2.25.15 or better is required. The latest version of
*** GLIB is always available from ftp://ftp.gtk.org/pub/gtk/.

^?@TAL-WINDOWS /src/gdk-pixbuf-2.22.1
$

I have found a similar problem on Ubuntu Forums(in GLib, different versions), and they told there that if you don't have the source tarball you've compiled older GLib(my case),you can do it by configuring a newer version and do this:
./configure [same parameters that needed(like prefix, which is "/mingw")]
make
make uninstall

I thought it would uninstall both version I've installed, but when I reinstall newer version of GLib from source, Pixbuff's configuration return same error.
So I've still tried fixing that, so I uninstall(again) newer version, and checked in the "glib-dev_2.26.1-1_win32.zip" for every file, and remove every match I found in "/mingw". Then off-course, reinstall the newer version from source.
I thought that by removing the binaries&dev files I copied, I would solve the mess I've created. But same error occurs in every approach I've mentioned!
Note: After "make uninstall" in the newer version, Pixbuff tell me it cannot find GLib at all in pkg-config, not a single word about 2.26.1.

I asks cause you guys probably know how configuration is done.
Any way to solve this mess?
Reply | Threaded
Open this post in threaded view
|

Re: GLib co-exiting dependency problem, kinda my fault...

Tor Lillqvist
> Any way to solve this mess?

The best way to solve it is to know what you are doing.

Some hints:
- You might want to set the PKG_CONFIG_PATH environment variable so
that pkg-config finds the specific stuff you want it to find. And no,
I don't mean set it system-wide, but in the specific shell instance
where you build something.
- Don't ever overwrite stuff installed from a "package" (like the
zipfiles from www.gtk.org) with "make install" in something you build
yourself. That just leads to confusion. Instead, install stuff you
build yourself into a different prefix. Use PATH and PKG_CONFIG_PATH
to select what dependencies you want to refer to when building
something.
- Write small shell functions to set PATH and PKG_CONFIG_PATH in
various ways so that you don't need to type long commands manually.

--tml

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
MinGW-users mailing list
[hidden email]

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

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Tal
Reply | Threaded
Open this post in threaded view
|

Re: GLib co-exiting dependency problem, kinda my fault...

Tal
I didn't understand what you told me very much, so I'll try to response you:

> The best way to solve it is to know what you are doing.
Thats what I ask here :-) And please see how I tried to deal with my problem(in various ways).
None of them were risky. I can remove those files because I know that I have the zip file in my downloads.
So if something go wrong, I'll just copy the files again.
But it's true I didn't know what I was doing when I decided to copy binaries&devs.

>- You might want to set the PKG_CONFIG_PATH environment variable so
>that pkg-config finds the specific stuff you want it to find. And no,
>I don't mean set it system-wide, but in the specific shell instance
>where you build something.
This is not the mess, see my PKG_CONFIG_PATH value:
C:\MinGW\msys\1.0\lib\pkgconfig;C:\mingw32\lib\pkgconfig;
After uninstalling GLib, none of them include the GLib .pc file.

>- Don't ever overwrite stuff installed from a "package" (like the
>zipfiles from www.gtk.org) with "make install" in something you build
>yourself. That just leads to confusion. Instead, install stuff you
>build yourself into a different prefix. Use PATH and PKG_CONFIG_PATH
>to select what dependencies you want to refer to when building
>something.
I'll keep this in mind. But it still doesn't explain my problem. I was making sure that it will be uninstalled(after "make uninstall") by passing every file that is in the "zip", and delete it from mingw root(/mingw) if it still exist.
Then, I tried to install again from source. It didn't work.
This is why I don't care to remove files that exist in the zip.
However, I wouldn't dare doing this to my Debian machine.

>- Write small shell functions to set PATH and PKG_CONFIG_PATH in
>various ways so that you don't need to type long commands manually.
I prefer just to manually change the variables in "my computer" properties.
I'm not pro... And as you saw above, I didn't install it in a different prefix.

>--tml
I think you mean deleting it from "/src/tml". I did.

Again, I ask here because you know where the configure script check for dependencies.
I tried to read by my my own the "configure" script, I can found the
"pkg-config --modversion glib-2.0", but I don't know how he "knows" that
the older version exist.
BTW: People told me not to write more than 72 character in a row(use auto-break).
I thought that if I post in the MinGW .n2.nabble.com archive manually it will
auto-break for me, but it's not. How to?
Reply | Threaded
Open this post in threaded view
|

Re: GLib co-exiting dependency problem, kinda my fault...

John Brown

Hello Tai,
Tai wrote:
> This is not the mess, see my PKG_CONFIG_PATH value:
> C:\MinGW\msys\1.0\lib\pkgconfig;C:\mingw32\lib\pkgconfig;
> After uninstalling GLib, none of them include the GLib .pc file.
>
Pkg-config may have hard-coded  paths that it searches *in addition to*
the path that you set in PKG_CONFIG_PATH.
>
> Again, I ask here because you know where the configure script check for
> dependencies.
> I tried to read by my my own the "configure" script, I can found the
> "pkg-config --modversion glib-2.0", but I don't know how he "knows" that
> the older version exist.

Run the following command in a MSYS shell:
pkg-config --debug 2>&1 | grep Scanning
and it will show you the directories that it searches for .pc files.

Regards,
Alias John Brown.
     
------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
MinGW-users mailing list
[hidden email]

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

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: GLib co-exiting dependency problem, kinda my fault...

Michael T.
In reply to this post by Tor Lillqvist

> The best way to solve it is to know what you are doing.
>
> Some hints:
> - You might want to set the PKG_CONFIG_PATH environment variable so
> that pkg-config finds the specific stuff you want it to find. And no,
> I don't mean set it system-wide, but in the specific shell instance
> where you build something.
> - Don't ever overwrite stuff installed from a "package" (like the
> zipfiles from www.gtk.org) with "make install" in something you build
> yourself. That just leads to confusion. Instead, install stuff you
> build yourself into a different prefix. Use PATH and PKG_CONFIG_PATH
> to select what dependencies you want to refer to when building
> something.
> - Write small shell functions to set PATH and PKG_CONFIG_PATH in
> various ways so that you don't need to type long commands manually.
>
> --tml


Tor, you should write two books.
One on basic programming skills.
The second one on organizing stuff, hints and neat programming in  linux-like programming environemnts.

I'm serious. I'd buy both.

Secondly, I'd like to give one BIG HUGE THANKS to everybody participating on this list. Beginning with Keith and Earnie.
This is an amazing list with tremendously wise people on it and I've learnt so much from you guys.
This is something a commercial product never delivers. Thanks for doing it and thanks for doing it for free!

michael


 

> ------------------------------------------------------------------------------
> What Every C/C++ and Fortran developer Should Know!
> Read this article and learn how Intel has extended the reach of its
> next-generation tools to help Windows* and Linux* C/C++ and Fortran
> developers boost performance applications - including clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> MinGW-users mailing list
> [hidden email]
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same.  Disregard for the list etiquette may
> cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:[hidden email]?subject=unsubscribe
>
>
>

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
MinGW-users mailing list
[hidden email]

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

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Tal
Reply | Threaded
Open this post in threaded view
|

Re: GLib co-exiting dependency problem, kinda my fault...

Tal
In reply to this post by John Brown
Hi John,
I typed "pkg-config --debug 2>&1 | grep Scanning " and it shows only those 2 directories I mentioned.
Do you know where configure script search at?
Thanks again,
Tal
Reply | Threaded
Open this post in threaded view
|

Re: GLib co-exiting dependency problem, kinda my fault...

Tor Lillqvist
In reply to this post by Tal
> This is not the mess, see my PKG_CONFIG_PATH value:
> C:\MinGW\msys\1.0\lib\pkgconfig;C:\mingw32\lib\pkgconfig;

Isn't this weird? You shouldn't be mixing MSYS libraries and native
Windows (MinGW) libraries, should you?

Also, note that a MSYS pkg-config should use Unix style pathnames etc
(and will not do any of the Windows-specific things pkg-config does).
A Windows pkg-config is "clever" and automatically relocatable, it
deduces where to look for .pc files by default from where it's exe is
located. A Unix (i.e. MSYS in this case) pkg-config does not, and
should not, as Unix packages are typically installed in locations
fixed by the packager. Which type of pkg-config are you using?

--tml

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
MinGW-users mailing list
[hidden email]

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

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Tal
Reply | Threaded
Open this post in threaded view
|

Re: GLib co-exiting dependency problem, kinda my fault...

Tal
The reason I inserted ..../msys/1.0/lib/pkgconfig to this variable was simple.
MinGW-get can install libxml2 only in MSYS. There is "msys-libxml2.xml",
but no "mingw32-libxml2.xml" in it. That's why I needed to include this
MSYS-pkgconfig directory to this environment variable.
I don't know how to answer to your last question. "pgg-config.exe" is located
in C:\MinGW\bin. There's no such file in msys\1.0\bin.
Reply | Threaded
Open this post in threaded view
|

Re: GLib co-exiting dependency problem, kinda my fault...

Tor Lillqvist
> MinGW-get can install libxml2 only in MSYS. There is "msys-libxml2.xml",
> but no "mingw32-libxml2.xml" in it. That's why I needed to include this
> MSYS-pkgconfig directory to this environment variable.

But if msys-libxml2 is a MSYS library, as one would guess, you can not
use it in non-MSYS code.

--tml

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
MinGW-users mailing list
[hidden email]

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

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: GLib co-exiting dependency problem, kinda my fault...

JonY-3
In reply to this post by Tal
On 5/23/2011 18:13, Tal wrote:
> The reason I inserted ..../msys/1.0/lib/pkgconfig to this variable was
> simple.
> MinGW-get can install libxml2 only in MSYS. There is "msys-libxml2.xml",
> but no "mingw32-libxml2.xml" in it. That's why I needed to include this
> MSYS-pkgconfig directory to this environment variable.
> I don't know how to answer to your last question. "pgg-config.exe" is
> located
> in C:\MinGW\bin. There's no such file in msys\1.0\bin.
>

Those are for MSYS, not MinGW, remove it from your search path when
using MinGW.

I'm beginning to wonder if its a good idea to have those available to
users installing via mingw-get. Its sad that users need to be protected
from themselves sometimes.


------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
MinGW-users mailing list
[hidden email]

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

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

0xED74C077.asc (1K) Download Attachment
signature.asc (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GLib co-exiting dependency problem, kinda my fault...

Charles Wilson-2
On 5/23/2011 6:39 AM, JonY wrote:
> Those are for MSYS, not MinGW, remove it from your search path when
> using MinGW.
>
> I'm beginning to wonder if its a good idea to have those available to
> users installing via mingw-get. Its sad that users need to be protected
> from themselves sometimes.

But I'd rather not make life practically impossible for us msys devs.


In general, pkg-config files in the msys hierarchy are only available if
the user has installed a msys-foo-*-dev package.  Perhaps this should be
one of our standard diagnostic questions:

1) are you trying to build an msys app or a mingw app (and if the answer
is msys, find out why...most users should not be doing that).

2) if mingw (which should be the most common answer), then have you
installed ANY msys-*-dev packages?  (pointer to mingw-get-info script).
If so, why?

--
Chuck

------------------------------------------------------------------------------
What Every C/C++ and Fortran developer Should Know!
Read this article and learn how Intel has extended the reach of its
next-generation tools to help Windows* and Linux* C/C++ and Fortran
developers boost performance applications - including clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
MinGW-users mailing list
[hidden email]

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

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: GLib co-exiting dependency problem, kinda my fault...

JonY-3
On 5/23/2011 22:09, Charles Wilson wrote:

> On 5/23/2011 6:39 AM, JonY wrote:
>> Those are for MSYS, not MinGW, remove it from your search path when
>> using MinGW.
>>
>> I'm beginning to wonder if its a good idea to have those available to
>> users installing via mingw-get. Its sad that users need to be protected
>> from themselves sometimes.
>
> But I'd rather not make life practically impossible for us msys devs.
>
>
> In general, pkg-config files in the msys hierarchy are only available if
> the user has installed a msys-foo-*-dev package.  Perhaps this should be
> one of our standard diagnostic questions:
>
> 1) are you trying to build an msys app or a mingw app (and if the answer
> is msys, find out why...most users should not be doing that).
>
> 2) if mingw (which should be the most common answer), then have you
> installed ANY msys-*-dev packages?  (pointer to mingw-get-info script).
> If so, why?
>
> --
> Chuck
So, installing MSYS dev packages requires users to answer question
instead of just clicking OK and forcing them to read? That might be a
good idea.


------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
MinGW-users mailing list
[hidden email]

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

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe

0xED74C077.asc (1K) Download Attachment
signature.asc (203 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: GLib co-exiting dependency problem, kinda my fault...

Charles Wilson-2
On 5/23/2011 6:42 PM, JonY wrote:

> On 5/23/2011 22:09, Charles Wilson wrote:
>> Perhaps this should be
>> one of our standard diagnostic questions:
>>
>> 1) are you trying to build an msys app or a mingw app (and if the answer
>> is msys, find out why...most users should not be doing that).
>>
>> 2) if mingw (which should be the most common answer), then have you
>> installed ANY msys-*-dev packages?  (pointer to mingw-get-info script).
>> If so, why?
>
> So, installing MSYS dev packages requires users to answer question
> instead of just clicking OK and forcing them to read? That might be a
> good idea.

Oh, uh, I was referring to diagnostic questions here, on this list, when
folks come asking questions.  I wasn't really talking about making
changes to the mingw-get-inst GUI installer.

When you said "I'm beginning to wonder if its a good idea to have those
available to users installing via mingw-get" I was thinking
'mingw-get.exe' -- and the only way to "remove" them from that, was to
completely remove their manifests from the catalogue.  Which would mean
msys devs would have to manually download and untar the msys-dev
packages.  Hence: bad idea.

Now, we've ALREADY changed mingw-get-inst GUI so that it does not
present the option to install the 'MSYS System Builder' -- ie. the
msys-dev pacakges -- at all.  This happened with the 20110211 release:

        * Remove 'MSYS System Builder' from GUI selection dialog. Too
          many novice users were installating it without understanding
          its purpose, leading to a lot of confusion on the mailing list.

          ************************************************************
          ** Most people should not install the MSYS System Builder **
          ** It is for building MSYS applications and libraries.    **
          ** As most users want to build MinGW (that is, native     **
          ** win32) applications and libraries, it is inappropriate **
          ** to install the MSYS System Builder.  However, if you   **
          ** really want to install it, use the command line tool   **
          **         'mingw-get install msys-dvlpr'                 **
          ** AFTER you install the other components using this GUI  **
          ** installation process. But DO NOT DO THIS unless you    **
          ** really understand the implications.                    **
          ************************************************************


--
Chuck

------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
MinGW-users mailing list
[hidden email]

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

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Tal
Reply | Threaded
Open this post in threaded view
|

Re: GLib co-exiting dependency problem, kinda my fault...

Tal
Thank you guys, I found the problem. There was glib binary
in some another address on my $PATH.
Now I have new problem- Gdk-Pixbuf configures well, but it
shows errors in "make".
This is the error:

...
make[4]: Entering directory `/src/gdk-pixbuf-2.22.1/gdk-pixbuf/pixops'
/bin/sh ../../libtool  --tag=CC   --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H
-I. -I../.. -I../.. -I../..  -mms-bitfields -IC:/mingw/include/glib-2.0 -IC:/min
gw/lib/glib-2.0/include -IC:/mingw/include/libpng15  ☺   -DG_DISABLE_SINGLE_INCL
UDES -I/mingw/include  -DGDK_PIXBUF_DISABLE_DEPRECATED -g -O2 -Wall -mms-bitfiel
ds -MT pixops.lo -MD -MP -MF .deps/pixops.Tpo -c -o pixops.lo pixops.c
libtool: compile:  gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../.. -m
ms-bitfields -IC:/mingw/include/glib-2.0 -IC:/mingw/lib/glib-2.0/include -IC:/mi
ngw/include/libpng15 ☺ -DG_DISABLE_SINGLE_INCLUDES -I/mingw/include -DGDK_PIXBUF
_DISABLE_DEPRECATED -g -O2 -Wall -mms-bitfields -MT pixops.lo -MD -MP -MF .deps/
pixops.Tpo -c pixops.c  -DDLL_EXPORT -DPIC -o .libs/pixops.o
gcc.exe: ☺: Invalid argument
make[4]: *** [pixops.lo] Error 1

I don't know if you can see what the char is, so the char is a
Unicode smiley. The error make sense, there should not be
smiley in arguments.(right?)
I've searched and found another guy which have the exact weird
issue in MinGW:
http://mail.gnome.org/archives/gtk-list/2004-October/msg00139.html
Note this issue seems to exist since 2004, even when back then
this package was included in GTK tar.(see he's PWD)

Anyone knows how to deal with it?