GTK/GDK-related packages

talsamon

talsamon

Can't update gtk3, libsoup, atk, gdk-pixbuf2 and glib-networking (maybe there also another).

graphics/gdk-pixbuf2 means

Code: 
checking for GLIB - version >= 2.37.6... *** GLIB header files (version 2.36.3) do not match
*** library (version 2.42.0)

net/glib-networking means
Code: 
checking for GLIB - version >= 2.39.1... *** GLIB header files (version 2.36.3) do not match
*** library (version 2.42.0)

locate libglib-2.0.so
Code: 
/compat/linux/lib/libglib-2.0.so.0
/compat/linux/lib/libglib-2.0.so.0.2800.8
/usr/local/lib/libglib-2.0.a
/usr/local/lib/libglib-2.0.so
/usr/local/lib/libglib-2.0.so.0
/usr/local/lib/libglib-2.0.so.0.3600.3
/usr/local/lib/libglib-2.0.so.0.4200.0

pkg info glib
Code: 
Name  : glib
Version  : 2.42.0

On a 10.1 system - on two other 10.1 systems - no problem.
Other packages compiles without problems.
 
Seems solved - I deleted all files in /usr/local/include/glib-2.0/glib/ (there are only header-files) and recompiled glib20 - and the packages I need compile fine. It would be interesting, how this could happen.
 
Most likely the port would have to be compiled in a clean environment with no previous version of the port or anything related to it installed. Yet another reason why FreeBSD ports should use a clean chroot(8) by default for compiling ports to avoid this type of problems.
 
Sorry, got my wires crossed. How should this work - and where to chroot? Is there any link that explains this? I don't want to copy half the system in chroot. And man explains nothing - it's only a lexicon of parameters.
 
What I mean is a similar system that ports-mgmt/poudriere uses to set up a completely clear environment for the ports to build in, it just uses jails because there's more machinery in them for easier automatic set up. Only the absolutely necessary dependencies get installed from packages before the port building commences. This guarantees that the old versions can not interfere like they do now when the building happens in the "live system".
 
Sorry, may be I am stupid. But I do not understand the sense of a chroot of /usr/port (or ever you name the directory). Either I mount all the bin, sbin, lib, libexec, etc - directories or I select all the file I need (if I search all the files, I get old). If I copy all the, is waste of disk and had the same effect as I mount all of them. And then I have the same environment as before.
 
Greetings,
Your problem most is likely related to ld(1). The port, or another port either didn't run ldconfig(8) after installing the libraries, or was possibly interrupted somehow, during the process. In any case, ld(1) was unable to discover the addition of the newer version of the library. A "cleanroom" is nice for testing. But it's often more expediant to simply clobber the offending libraries, and simply perform a clean installation -- crude, but effective. OTOH if you don't know the offender, or don't know which libraries are the newer, or needed versions. Things become a bit trickier. pkg(8) has been helpful in determining that sort of thing, though.

All the best.

--Chris
 
No, it is not. Today, just at the moment, I install another machine. The glib error is back, and my solution from above does not work.
This is not my fault. This error was never before. It 's a specific 10.1 error. (Angry!).

didn't run ldconfig(8) after installing
Click to expand...

Which library? And what's this, never heard before, this not my work ldconfig should be work of the port.
 
How does this work? And how should I know which library per port - or generally, man doesn't help, how ever. No I am wrong it's not 10.1 - it's something with the GNOME/GTK update.
 
I remove all dependent ports trying to reinstall glib - how could that be - if there's nothing there the could not find an older package? It's horrible. Which file keeps the old information?
 
I got it - but don't ask me how. I don't know it. I delete like above - and experimented with ldconfig after deinstall, before deinstall - something worked - but the thing "ldconfig" isn't clear. In the first line WHEN do I have I to use it? In which case.
 
What I was speculating on. Is that the port, or some port you are installing isn't registering it's library, or libraries, via ld(1)/ldconfig(8), when it installs them. You shouldn't have to concern yourself with either ld(1), or ldconfig(8). It's the (port) maintainers job to see that all of this is done properly. I only mentioned it, because that is what appears to be the trouble/problem. If you know which port, or ports are causing the problem. You should inform the maintainer, by sending a pr(1). The support section provides more information, on how to accomplish that. Without more specific details, that's the best I have to offer.

All the best.

--Chris
 
OK. I just performed a bit of investigation, by grep(1)ping the output of [man=8]pkg[/man] info. I'm writing this from a RELENG_9 based system (9.3-STABLE). It also has all the libraries you indicate you're experiencing trouble with. But I have no trouble. What is the output of
svn info /usr/ports
I would like to compare revisions. I maintain ~60 servers. I could compare the revisions against the one you're currently running.

--Chris
 
Code: 
svn info
Path: .
Working Copy Root Path: /usr/src
URL: http://svn.freebsd.org/base/release/10.1.0
Relative URL: ^/release/10.1.0
Repository Root: http://svn.freebsd.org/base
Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
Revision: 274840
Node Kind: directory
Schedule: normal
Last Changed Author: gjb
Last Changed Rev: 274417
Last Changed Date: 2014-11-12 09:20:25 +0100 (Mi, 12 Nov 2014)
 
Greetings, talsamon.
Close. But I asked for the revision of your ports tree. :)
svn info /usr/ports
If you could provide that. I might be able to help. :)

--Chris
 
There is none.
Code: 
svn info /usr/ports/
subversion/svn/info-cmd.c:663,
subversion/libsvn_client/info.c:290,
subversion/libsvn_wc/info.c:529,
subversion/libsvn_wc/node.c:505,
subversion/libsvn_wc/wc_db.c:8734,
subversion/libsvn_wc/wc_db_wcroot.c:629: (apr_err=SVN_ERR_WC_NOT_WORKING_COPY)
svn: E155007: '/usr/ports' is not a working copy

I update with portsnap. Is there a need for this?
 
I made one:
Code: 
svn info /usr/ports/
Path: .
Working Copy Root Path: /usr/ports
URL: http://svn.freebsd.org/ports
Relative URL: ^/
Repository Root: http://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 373036
Node Kind: directory
Schedule: normal
 
That was wrong, the usual chaos with svn.

Code: 
sudo svn info RELEASE_10_1_0/
Path: RELEASE_10_1_0
Working Copy Root Path: /usr/ports/RELEASE_10_1_0
URL: http://svn.freebsd.org/ports/tags/RELEASE_10_1_0
Relative URL: ^/tags/RELEASE_10_1_0
Repository Root: http://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 373064
Node Kind: directory
Schedule: normal
Last Changed Author: bapt
Last Changed Rev: 372026
Last Changed Date: 2014-11-01 19:32:57 +0100 (Sa, 01 Nov 2014)

Don't know what the right branch is, I hope this one.
 
talsamon said:
That was wrong, the usually chaos with svn.

Code: 
sudo svn info RELEASE_10_1_0/
Path: RELEASE_10_1_0
Working Copy Root Path: /usr/ports/RELEASE_10_1_0
URL: http://svn.freebsd.org/ports/tags/RELEASE_10_1_0
Relative URL: ^/tags/RELEASE_10_1_0
Repository Root: http://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 373064
Node Kind: directory
Schedule: normal
Last Changed Author: bapt
Last Changed Rev: 372026
Last Changed Date: 2014-11-01 19:32:57 +0100 (Sa, 01 Nov 2014)

Don't know whats the right branch is, I hope this one.
Click to expand...

Don't use that one, it's just a snapshot from the time of the 10.1-RELEASE to mark it on the repository and it will never be updated. The correct one is always head unless you want to use one of the quarterly branches from https://svnweb.freebsd.org/ports/branches/.
 
Very, very fine. I do that now for the fifth time. One was an error of mine. Each two hours, I hate svn. I love cvsup.
 
You must log in or register to reply here.
Back
Top