Opened 3 years ago

Closed 3 years ago

#225 closed enhancement (fixed)

qmake: Keep long names in import libraries

Reported by: dmik Owned by:
Priority: major Milestone: Qt 4.7
Component: General Version: 4.6.3
Severity: low Keywords:
Cc:

Description

In order to overcome the 8.3 DLL file name format limitation imposed by OS/2 we introduced the TARGET_SHORT qmake variable that specifies the alternative name for the DLL being built that is intended to fit the 8.3 limitation. Besides with the DLL name itself, both the corresponding import library and the .prl files get this short name as well.

Given that all other platforms supoprt long DLL names, applications link to these DLLs at build time through their import libraries by simply doing LIBS += MyLongDLLName. This doesn't work on OS/2 (since the import library name is shortened by TARGET_SHORT to something like MyDLLLib) and therefore requires a modification in each .pro file linking to that library. When linking to Qt libraries itself, all the magic is done in mkspecs files and the problem is not visible for the end user, but in custom applications it pops up.

Taking into account that it is not really necessary for the .lib file to have the same name as the .DLL file, nor it is so for the .prl file, I will change the relevant code so that the name of the .lib or .prl file is not shortened any more by making sure that TARGET_SHORT only affects the .dll name itself and also the name of the respective .def and .map files (which is necessary for obvious reasons, both describe the DLL, not the import library or anything else).

Change History (5)

comment:1 Changed 3 years ago by dmik

Actually, in case of Qt itself, we don't do anything special to shorten import library names: applications refer to them by full name. The reason why it works is due to the 'link_prl' CONFIG option. When it is present, qmake will first search for a respective .prl file (which is always fully named) and then read its QMAKE_PRL_TARGET variable to detect the (short) name of the import library to use. It means that if you add 'create_prl' and 'link_prl' into your application, it will work for you as well w/o the need to specify the short name of the import library in LIBS directly.

However, there is still no need for the .lib file to carry the short name and the applications don't actually use these 'create_prl/link_prl' options so I will fix it anyway.

comment:2 Changed 3 years ago by dmik

Done in r886. Will leave it open until I check that Qt and Qt creator fully build with this change.

comment:3 Changed 3 years ago by dmik

I also rolled back r162 and r804 as they are not necessary any more.

Note that it may actually become necessary once there is a case where .prl controlled library name translation is used somewhere again -- but that's a general qmake flaw present on all platforms. I just restored it since OS/2 doesn't require library name translation through .prl now.

r410 is also worth mentioning. It was also done to make sure .prl library name translation works right. However, I didn't roll it back because it looks sane on its own.

Last edited 3 years ago by dmik (previous) (diff)

comment:4 Changed 3 years ago by diver

this works now as it seems. but i found some dll names which are too long.
they are located in the plugins dir.

comment:5 Changed 3 years ago by dmik

  • Resolution set to fixed
  • Status changed from new to closed

Long DLL names are fixed in r890.

The new qmake seems to work well.

Note: See TracTickets for help on using tickets.