Community Packages

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!
Tasklist

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
Task Type Bug Report
Category Packages
Status Closed
Assigned To Alexander F. Rødseth (xyproto)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

I 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
Comment by Alexander F. Rødseth (xyproto) - Thursday, 05 September 2013, 11:51 GMT
Hi, thanks for the bug report.

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.
Comment by Alexander F. Rødseth (xyproto) - Friday, 06 September 2013, 11:07 GMT
Fixed. Please reopen this ticket and/or fill new bug reports or feature requests if there should be further issues.

The updated package will appear in [community] shortly.
Comment by Alexander F. Rødseth (xyproto) - Friday, 06 September 2013, 11:09 GMT
As a sidenote, being able to do something like:

./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)
Comment by Mark Tyler (mt) - Friday, 06 September 2013, 18:21 GMT
The update seems to work well from my perspective.

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.
Comment by Alexander F. Rødseth (xyproto) - Saturday, 07 September 2013, 09:20 GMT
I'm glad that the mtpaint package now appears to contain the right elements.

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.

Loading...