Pandora pkg-config strangeness (codeblocks PND)

[Galaxis]

Ok, so I'm somewhat stumped currently, as pkg-config from /mnt/utmp/codeblocks/usr/bin/pkg-config produces broken info...

I have (for example) a .pc file with the following content:


prefix=/mnt/utmp/codeblocks/home/src/vlc-2.0.5/contrib/native
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
Name: libmpeg2
Description: MPEG-1 and MPEG-2 stream decoding library
Version: 0.5.1
Libs: -L${libdir} -lmpeg2
Cflags: -I${includedir}/mpeg2dec

...but when I run pkg-config --debug --cflags "libmpeg2" I get the following output:


Parsing package file '/mnt/utmp/codeblocks/home/src/vlc-2.0.5/contrib/native/lib/pkgconfig/libmpeg2.pc'
  line>prefix=/mnt/utmp/codeblocks/home/src/vlc-2.0.5/contrib/native
 Variable declaration, 'prefix' has value '/mnt/utmp/codeblocks/home/src/vlc-2.0.5/contrib/native'
  line>exec_prefix=${prefix}
 Variable declaration, 'exec_prefix' has value '/mnt/utmp/codeblocks/usr'
  line>libdir=${exec_prefix}/lib
 Variable declaration, 'libdir' has value '/mnt/utmp/codeblocks/usr/lib'
  line>includedir=${prefix}/include
 Variable declaration, 'includedir' has value '/mnt/utmp/codeblocks/usr/include'
  line>
  line>Name: libmpeg2
  line>Description: MPEG-1 and MPEG-2 stream decoding library
  line>Version: 0.5.1
  line>Libs: -L${libdir} -lmpeg2
  line>Cflags: -I${includedir}/mpeg2dec

WTF!?

Why does it tell me "prefix" has a certain value, and after exec_prefix=${prefix}, the variable exec_prefix contains something else?

Does anyone have an idea what I have to look at? It's not something from the global environment...

 

[ptitSeb]

Hum, there is some hardcoded change in the pkg-config, that force ${prefix} to "$CDEVROOT/usr"

You should use another name, or comment all line but the first and the last in 'pkg-config'

I will see if I can get rid of this, as I already changed all ".pc" file by hand.

 

[Galaxis]

Argh :blink:

That cost me a couple of hours of useless bug hunting (including an embarrassing bug report with the VLC people, who told me that 1) it's not their fault, 2) I'm dumb, and 3) my build system is broken)... Turns out they were right

No worries though, should have asked earlier...

 

[ptitSeb]

sorry for this... Having non standard path does come with a price, sadly...

 

[Galaxis]

I'll keep that in mind for the future... Unfortunately, $prefix is not something I can choose to change in this context, as those files are generated automatically... I'll just fix them up with a hardcoded path for now, sed to the rescue...

Despite that small mishap, thanks a lot for creating the PND in the first place - otherwise I wouldn't be dabbling with porting stuff at all right now

 

[ptitSeb]

Thank you. Freamon deserves most of the credits, for creating the cdtools.pnd, from wich codeblocks derived.

 

[freamon]

... and most of the blame too.

The thing to realise is that /mnt/utmp/codeblocks/usr/bin/pkg-config is not a binary, it's just a text file that calls the real pkg-config with the --prefix=/mnt/utmp/codeblocks/usr override.

In the cdevtools PND, all the pc files still have the prefix value from Angstrom (i.e. /usr), so it makes sense to override them. If ptitSeb has changed the prefix in all the pc files, then it'll be okay to edit the pkg-config text file to take out the override, and that'll give you the behaviour you're expecting from it.

 

[Galaxis]

Ok, I'll try that.

I have another question for ptitSeb, while I'm at it (different topic) - I have noticed that some changes from the codeblocks PND seem to leak over into the global environment (ldconfig, possibly?): When the codeblocks PND is open, other PNDs start to pick up libraries from the codeblocks path. This leads to some breakage - for example, on my system, it isn't possible to run PNDmanager anymore, as it loads some incompatible shared lib from codeblocks and dies on that.

Also, as other programs access shared libraries from codeblocks, it isn't possible unmount the PND anymore. Haven't had a look at the startup scripts yet, but I think - if at all possible - the changes should be contained within codeblocks...

 

[ptitSeb]

Ok, I'll try that.

I have another question for ptitSeb, while I'm at it (different topic) - I have noticed that some changes from the codeblocks PND seem to leak over into the global environment (ldconfig, possibly?): When the codeblocks PND is open, other PNDs start to pick up libraries from the codeblocks path. This leads to some breakage - for example, on my system, it isn't possible to run PNDmanager anymore, as it loads some incompatible shared lib from codeblocks and dies on that.

Also, as other programs access shared libraries from codeblocks, it isn't possible unmount the PND anymore. Haven't had a look at the startup scripts yet, but I think - if at all possible - the changes should be contained within codeblocks...

Yes, it's the "ldconfig" effect. It's system wide, and prevent PNDManager to run (I think the QT4 version in Code::Blocks is outdated compare to the one in PNDManager). To simulate "unmount" you can do:


sudo ldconfig

that will stop the system to link with the libs in codeblocks...

Then, when you have finished, you do


sudo ldconfig -f /mnt/utmp/codeblocks/init/ld.so.cfg

and you can continu to use codeblocks (I do this many times because I've alway codeblocks mounted)

Also, I have put an "hidden" option in the latest codeblocks to unmount cleanly when you exit: create a dummy file named "clean_pnd" inside the appdata/codeblocks/init/ folder, and you will be asked for you sudo password at the exit to cleanly unmount (i.e. call the "sudo ldconfig" command).

 

[Galaxis]

[worked around that one, post deleted]