Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#36796 - [mtpaint] 3.40-12 LDFLAGS problem
Attached to Project:
Community Packages
Opened by Mark Tyler (mt) - Thursday, 05 September 2013, 10:44 GMT
Last edited by Alexander F. Rødseth (xyproto) - Saturday, 07 September 2013, 09:21 GMT
Opened by Mark Tyler (mt) - Thursday, 05 September 2013, 10:44 GMT
Last edited by Alexander F. Rødseth (xyproto) - Saturday, 07 September 2013, 09:21 GMT
|
DetailsI noticed that the compiled mtpaint binary has a lot of needless dependencies. I think this is because of the way the configure script handles LDFLAGS set in /etc/makepkg.conf, so to solve this problem, sed can be used:
# Ensure that -Wl,--as-needed in /etc/makepkg.conf is respected. sed -i 's:$LIBS $LDFLAGS:$LDFLAGS $LIBS:' configure This will be useful for all distros, so it may be worth contacting upstream. The alternative is to use the asneeded configure argument, but this doesn't feel right to me as its better to support the system wide LDFLAGS directly as this also has other settings that need to be respected. I noticed in the development version of mtPaint that the Giflib 5 problems have been fixed, so a quick comment before those sed commands could be handy for future maintainers to understand what is going on without time consuming research: # Needed for giflib 5 build. Not required for versions after 3.40. In my earlier report I mentioned about jasper not being a dependency, but it has been left in without a comment. Was this an oversight or is there some deeper thought about this issue required? I realise its a bit of a political moot point as to which library to support as they both provide the same JPEG2000 facilities. I have no settled view myself, and merely comment to stimulate some thought. Dmitry has made the configure script check for openjpeg first, so I guess thats his preference. |
This task depends upon
Closed by Alexander F. Rødseth (xyproto)
Saturday, 07 September 2013, 09:21 GMT
Reason for closing: Fixed
Saturday, 07 September 2013, 09:21 GMT
Reason for closing: Fixed
I'll fix the LDFLAGS/LIBS problem.
About jasper, I think I misunderstood if you meant that it should be used or not in the previous bug report. Will fix this too.
Thanks.
The updated package will appear in [community] shortly.
./configure \
--enable-openjpeg \
--enable-freetype2 \
etc
Followed by just make and make install, would be preferable to the currently required method for building mtpaint.
Conventional ./configure, make and make install, in other words. (or cmake)
Using my name in the comment is very flattering, even a little humorous perhaps! However, I should put on the record that I haven't maintained mtPaint for over 7 years so I am just an average Joe user who has made a few observations, and shared them in the hope that they are useful.
This also relates to your suggestion about configure options, as Dmitry is the only person who makes those decisions these days (which is why I suggested in my report that you contact upstream, i.e. email Dmitry directly).
Having said that, I do think your suggestion is worth considering as it does make the configure script arguments more descriptive, more human readable, and less ambiguous with issues like libgif/libungif versus GIF/gif that was fixed in the previous report.
Even if you have not maintained mtPaint for years, it's fun to interact with the original author(s) of software for packages that one maintains. Especially when the software is named after the original author, for reasons I am unable to explain.
I will consider contacting Dmitry about configure/make, but if everything works as it should now, there seems to be little pressure to do so immediately.
Thanks! Closing this bug report now, feel free to email me at rodseth@gmail.com if you should have further comments.