Fix Qt library names in pkg-config files #19

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
4 participants
@mbunkus
Contributor

mbunkus commented Apr 15, 2012

Fix for mxe/mxe#18.

@mbunkus

This comment has been minimized.

Show comment Hide comment
@mbunkus

mbunkus Apr 16, 2012

Contributor

I have to admit that I'm a bit puzzled by this issue. First, I don't understand how Qt's pc files are generated in the first place as the source code archive doesn't contain them, nor file names that even look remotely like them. So they're generated somehow by Qt's build system.

Second, building Qt 4.8.1 natively on Linux (meaning without mxe) results in pc files with the correct library file name: without the "4". Granted, I was building shared libraries instead of static ones; however I'm still a bit perplex.

Contributor

mbunkus commented Apr 16, 2012

I have to admit that I'm a bit puzzled by this issue. First, I don't understand how Qt's pc files are generated in the first place as the source code archive doesn't contain them, nor file names that even look remotely like them. So they're generated somehow by Qt's build system.

Second, building Qt 4.8.1 natively on Linux (meaning without mxe) results in pc files with the correct library file name: without the "4". Granted, I was building shared libraries instead of static ones; however I'm still a bit perplex.

@stloeffler stloeffler referenced this pull request Apr 17, 2012

Merged

New package: poppler #21

@vog

This comment has been minimized.

Show comment Hide comment
@vog

vog Apr 18, 2012

Owner

I think that Mark might have some deeper insight into this topic.

Owner

vog commented Apr 18, 2012

I think that Mark might have some deeper insight into this topic.

@ghost ghost assigned mabrand Apr 18, 2012

@stloeffler

This comment has been minimized.

Show comment Hide comment
@stloeffler

stloeffler Apr 18, 2012

Contributor

After some grep'ing through the Qt sources, I found the following:
*.pc files seem to be generated by qmake. What triggers it, I don't know (i.e., why no .pc files are created for "normal" applications).

The relevant sources seem to be in qmake/generators and its subdirectories.
In particular, at lines 315-319 of qmake/generators/win32/winmakefile.cpp it seems that VER_MAJ is added to TARGET_VERSION_EXT, which in turn is used in lines 3243-3263 of qmake/generators/makefile.cpp to produce the "Libs: " section of the *.pc files. As far as I could determine, winmakefile.cpp is the only place where VER_MAJ is appended (which might explain why this does not occur on, say, Linux systems).

I didn't have time to test any of this (as I guess that would mean recompiling Qt), but maybe it's sufficient to comment out/remove the lines 315-319 of qmake/generators/win32/winmakefile.cpp

Contributor

stloeffler commented Apr 18, 2012

After some grep'ing through the Qt sources, I found the following:
*.pc files seem to be generated by qmake. What triggers it, I don't know (i.e., why no .pc files are created for "normal" applications).

The relevant sources seem to be in qmake/generators and its subdirectories.
In particular, at lines 315-319 of qmake/generators/win32/winmakefile.cpp it seems that VER_MAJ is added to TARGET_VERSION_EXT, which in turn is used in lines 3243-3263 of qmake/generators/makefile.cpp to produce the "Libs: " section of the *.pc files. As far as I could determine, winmakefile.cpp is the only place where VER_MAJ is appended (which might explain why this does not occur on, say, Linux systems).

I didn't have time to test any of this (as I guess that would mean recompiling Qt), but maybe it's sufficient to comment out/remove the lines 315-319 of qmake/generators/win32/winmakefile.cpp

@mbunkus

This comment has been minimized.

Show comment Hide comment
@mbunkus

mbunkus Apr 18, 2012

Contributor

Interesting. Thanks for investigating. However, we might also just use my proposed patch which has the benefit of already having been tested to work correctly :) Qt compilation always takes ~10 minutes even on my hexacore machine, and I'm not to keen n spending a lot of time on this, to be honest.

Contributor

mbunkus commented Apr 18, 2012

Interesting. Thanks for investigating. However, we might also just use my proposed patch which has the benefit of already having been tested to work correctly :) Qt compilation always takes ~10 minutes even on my hexacore machine, and I'm not to keen n spending a lot of time on this, to be honest.

@stloeffler stloeffler referenced this pull request Apr 18, 2012

Closed

Qt depends on host files #22

@mabrand

This comment has been minimized.

Show comment Hide comment
@mabrand

mabrand Apr 19, 2012

Owner

The .pc files are right. The libraries themselves are named incorrectly. I'm looking into it.

Owner

mabrand commented Apr 19, 2012

The .pc files are right. The libraries themselves are named incorrectly. I'm looking into it.

@mabrand

This comment has been minimized.

Show comment Hide comment
@mabrand

mabrand Apr 19, 2012

Owner

Actually, I think now that the .pc files are wrong. Static libraries are not supposed to have the version number, but the pkconfig generation in Qt build system doesn't seem to know that. Still looking into it.

Owner

mabrand commented Apr 19, 2012

Actually, I think now that the .pc files are wrong. Static libraries are not supposed to have the version number, but the pkconfig generation in Qt build system doesn't seem to know that. Still looking into it.

@mbunkus

This comment has been minimized.

Show comment Hide comment
@mbunkus

mbunkus Apr 19, 2012

Contributor

The static libraries, when compiled on Linux with a non-cross compiler, are also named without the '4' for Qt 4.8.1. So I'm not sure the library names are actually wrong -- usually only shared libraries have that version number component included.

Contributor

mbunkus commented Apr 19, 2012

The static libraries, when compiled on Linux with a non-cross compiler, are also named without the '4' for Qt 4.8.1. So I'm not sure the library names are actually wrong -- usually only shared libraries have that version number component included.

@mabrand

This comment has been minimized.

Show comment Hide comment
@mabrand

mabrand Apr 19, 2012

Owner

Moritz Bunkus wrote:

The static libraries, when compiled on Linux with a non-cross compiler, are also named without the '4' for Qt 4.8.1. So I'm not sure the library names are actually wrong -- usually only shared libraries have that version number component included.

Yes, I realized that after posting that comment. See the next comment.
Anyway, the bug is in qmake. I'm fixing it.

Mark

Owner

mabrand commented Apr 19, 2012

Moritz Bunkus wrote:

The static libraries, when compiled on Linux with a non-cross compiler, are also named without the '4' for Qt 4.8.1. So I'm not sure the library names are actually wrong -- usually only shared libraries have that version number component included.

Yes, I realized that after posting that comment. See the next comment.
Anyway, the bug is in qmake. I'm fixing it.

Mark

@mbunkus

This comment has been minimized.

Show comment Hide comment
@mbunkus

mbunkus Apr 19, 2012

Contributor

Great, thanks. I'll close this pull request then; there's also issue #18.

Contributor

mbunkus commented Apr 19, 2012

Great, thanks. I'll close this pull request then; there's also issue #18.

@mbunkus mbunkus closed this Apr 19, 2012

@mabrand

This comment has been minimized.

Show comment Hide comment
@mabrand

mabrand Apr 19, 2012

Owner

Problem was caused by upstream bug in qmake. Change has been proposed and imported into mxe.
Fixed in 44eaf2c.

Owner

mabrand commented Apr 19, 2012

Problem was caused by upstream bug in qmake. Change has been proposed and imported into mxe.
Fixed in 44eaf2c.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment