todays upgrade presented me with The following packages will be upgraded: argyll 1 upgraded, 2 newly installed, 0 to remove and 6 not upgraded. Need to get 5979 kB of archives. After this operation, 50.2 MB of additional disk space will be used. The old (1.5.x) argyll package was already weighing 7M, but this is almost a tenfold increase in size. Please investigate what's going wrong there.
Hello Michael, first thanks for your work this and the two other bugs. Am Donnerstag, den 25.09.2014, 18:45 +0200 schrieb Michael Biebl: [...] [...] I have just build the old (1.5.1-8) and the new (1.6.3-2) release. The packed size are: ls -lh insgesamt 8,7M -rw-r--r-- 1 jff jff 3,4M Sep 25 19:14 argyll_1.5.1-8_amd64.deb -rw-r--r-- 1 jff jff 4,6M Sep 25 19:14 argyll-dbg_1.5.1-8_amd64.deb -rw-r--r-- 1 jff jff 79K Sep 25 19:14 icc-utils_1.5.1-8_amd64.deb -rw-r--r-- 1 jff jff 169K Sep 25 19:14 libicc2_2.12+argyll1.5.1-8_amd64.deb -rw-r--r-- 1 jff jff 93K Sep 25 19:14 libicc-dev_2.12+argyll1.5.1-8_amd64.deb -rw-r--r-- 1 jff jff 369K Sep 25 19:14 libimdi0_1.5.1-8_amd64.deb -rw-r--r-- 1 jff jff 78K Sep 25 19:14 libimdi-dev_1.5.1-8_amd64.deb ls -lh insgesamt 31M -rw-r--r-- 1 jff jff 2,9M Sep 25 14:32 argyll_1.6.3-2_amd64.deb -rw-r--r-- 1 jff jff 26M Sep 25 14:32 argyll-dbg_1.6.3-2_amd64.deb -rw-r--r-- 1 jff jff 2,3M Sep 25 14:32 argyll-doc_1.6.3-2_all.deb -rw-r--r-- 1 jff jff 132K Sep 25 14:32 argyll-ref_1.6.3-2_all.deb -rw-r--r-- 1 jff jff 1,6K Sep 25 14:32 icc-utils_1.6.3-2_all.deb Without *-dbg are the sums 4.1M vs. 5M. The biggest increment comes from the dbg files. I build the programs with the gcc parameter -g. So I have a lot of more infos in the dbg files. I think that's ok. CU Jörg
Hello Michael, first thanks for your work this and the two other bugs. Am Donnerstag, den 25.09.2014, 18:45 +0200 schrieb Michael Biebl: [...] [...] I have just build the old (1.5.1-8) and the new (1.6.3-2) release. The packed size are: ls -lh insgesamt 8,7M -rw-r--r-- 1 jff jff 3,4M Sep 25 19:14 argyll_1.5.1-8_amd64.deb -rw-r--r-- 1 jff jff 4,6M Sep 25 19:14 argyll-dbg_1.5.1-8_amd64.deb -rw-r--r-- 1 jff jff 79K Sep 25 19:14 icc-utils_1.5.1-8_amd64.deb -rw-r--r-- 1 jff jff 169K Sep 25 19:14 libicc2_2.12+argyll1.5.1-8_amd64.deb -rw-r--r-- 1 jff jff 93K Sep 25 19:14 libicc-dev_2.12+argyll1.5.1-8_amd64.deb -rw-r--r-- 1 jff jff 369K Sep 25 19:14 libimdi0_1.5.1-8_amd64.deb -rw-r--r-- 1 jff jff 78K Sep 25 19:14 libimdi-dev_1.5.1-8_amd64.deb ls -lh insgesamt 31M -rw-r--r-- 1 jff jff 2,9M Sep 25 14:32 argyll_1.6.3-2_amd64.deb -rw-r--r-- 1 jff jff 26M Sep 25 14:32 argyll-dbg_1.6.3-2_amd64.deb -rw-r--r-- 1 jff jff 2,3M Sep 25 14:32 argyll-doc_1.6.3-2_all.deb -rw-r--r-- 1 jff jff 132K Sep 25 14:32 argyll-ref_1.6.3-2_all.deb -rw-r--r-- 1 jff jff 1,6K Sep 25 14:32 icc-utils_1.6.3-2_all.deb Without *-dbg are the sums 4.1M vs. 5M. The biggest increment comes from the dbg files. I build the programs with the gcc parameter -g. So I have a lot of more infos in the dbg files. I think that's ok. CU Jörg
Hi, Am 25.09.2014 um 21:57 schrieb Jörg Frings-Fürst: This is about installed package size. You are comparing the package sizes here, not the installed package size. Look at https://packages.debian.org/sid/argyll and compare the installed package size of 1.5 and 1.6 for amd64 (1.6.3-1): package size: 3,418.3 kB installed size: 52,195.0 kB for i386 (1.5) package size: 3,414.2 kB installed size: 7,490.0 kB
Am 25.09.2014 um 23:13 schrieb Michael Biebl: The difference between 1.5. and 1.6 seems to be, that the invididual binaries are much larger. Afaics, this is due to 1.5 using private libraries in /usr/lib/$(MULTIARCH)/argyll, which were shared among the binaries. In 1.6, they all link statically against those libs: For comparison $ du -hs /usr/bin/xicclu 28K /usr/bin/xicclu (1.5) $ objdump -x /usr/bin/xicclu | grep NEEDED NEEDED libxicc.so.0 (shared) NEEDED libargyllnum.so.0 (shared) NEEDED libicc.so.2 (shared) NEEDED libplot.so.0 (shared) NEEDED libm.so.6 NEEDED libc.so.6 $ du -hs /usr/bin/xicclu 1.5M /usr/bin/xicclu $ objdump -x /usr/bin/xicclu | grep NEEDED NEEDED libdl.so.2 NEEDED librt.so.1 NEEDED libX11.so.6 NEEDED libXext.so.6 NEEDED libXxf86vm.so.1 NEEDED libXinerama.so.1 NEEDED libXrandr.so.2 NEEDED libXau.so.6 NEEDED libXdmcp.so.6 NEEDED libXss.so.1 NEEDED libjpeg.so.8 NEEDED libm.so.6 NEEDED libpthread.so.0 NEEDED libc.so.6
I noticed the same issue. I think it is not sensible for this package to require >50 MB disk space. Is there any compelling reason for statically linking these binaries? I don't think that there is a relevant performance increase. So, please revert this change! Just my 2¢.
Hi, the major change between 1.5 and 1.6 was the build system change from the not upstream supported gnu make back to the upstream supported jam based system. With the current version the jam built system use no shared libraries. The problem is first the almost non-existent Jam documentation and second that the build environment was modified by upstream. Support from upstream tends to zero. So I have no way to change the use of the libraries. Therefore I close this bug. If anyone has any ideas for improvement, please reopen this bug. Thanks for your work CU Jörg
Hi, the major change between 1.5 and 1.6 was the build system change from the not upstream supported gnu make back to the upstream supported jam based system. With the current version the jam built system use no shared libraries. The problem is first the almost non-existent Jam documentation and second that the build environment was modified by upstream. Support from upstream tends to zero. So I have no way to change the use of the libraries. Therefore I close this bug. If anyone has any ideas for improvement, please reopen this bug. Thanks for your work CU Jörg
Am 09.05.2015 um 15:19 schrieb Jörg Frings-Fürst: Well, that's not a sufficient justification for closing the bug report. Please consider reopening the bug report and tagging it "help" instead.
Am 25.09.2014 um 21:57 schrieb Jörg Frings-Fürst: I has become even worse: argyll is now over 80 MB installed size. Please convince your upstream to switch to a reasonable build system if that is indeed a limitation of jam.
Hi!
As a regular user of argyll this itches enough for me to dig into the
Jam build system and to try to modify it so it uses shared libraries.
After downloading the current source package (version 1.7.0+repack) and
hacking at the Jam files I have arrived at a point where it builds, with
some caveats. See the attached patch.
I had to add libraries to the dependencies of various binaries. For
some reason it builds statically nevertheless.
The path where the shared libraries are looked for has to be set at
build time and is now hard coded to /usr/local/lib/argyll. In the older
Debian package argyll this was /usr/lib/x86_86-linux-gnu/argyll on my
machine. That would have to be set correctly somehow.
I have manually copied all shared libraries to their destination: cp
*/*.so */*/*.so /usr/local/lib/argyll/
The shared libraries are looked for by their name, like "libxicc.so".
In the earlier Debian package this was "libxicc.so.0" and so forth. I
haven't managed to have that, too.
I have also manually copied all binaries to /usr/local/bin/argyll with
something like this:
find -type f -a -perm +1 -a ! -name "*.so" -a ! -name "*.sh" -print0 |
xargs -0I{} cp {} /usr/local/bin/argyll/
This includes some binaries that are only required for building. I
have manually executed strip on all .so files and all binaries.
The result is about 6 MB libraries, 3 MB binaries. Better!
This is a proof that it works, and won't work out of the box on other
architectures. I hope that it serves as a starting point anyway.
Cheers,
Wolfgang Oertl
Wolfgang Oertl wrote: Hi, Currently it is an important objective of mine for the ArgyllCMS tools to be robustly portable, while executable size is a lesser consideration. So making the utilities dependent on the install of shared libraries is not something I want to take up in my general ArgyllCMS distribution. I don't like the approach you have use at all - modifying Jambase to make the LibraryFromObjects rule create shared libraries is a hack - the correct approach is to change the Jamfiles to have a "build shared library" option set from Jamtop/emvironment, and then invoke the appropriate ShLibraryFromObjects rule in each Jamfile etc. Not something I would do either, since it makes things non-movable. Instead I'd set the shared library path to point to where the executable are, i.e. use $ORIGIN. That way they can be locate anywhere, as long as the shared libraries go with them (see the SHLINKSEARCHEXEPATH variable in Jambase). Graeme Gill.
Hi! Thanks for joining the thread. Of course this patch is a rather ugly hack that is not portable. I don't know enough about Jam to properly implement that, but fortunately there are already parts in the makefiles (or rather, jamfiles) that enable shared libraries. My goal was to change as little as possible, so that until the upstream supports that (I have been waiting quite a few months now) it can be used in Debian. I noticed this $ORIGIN and wondered what it was :) It was late evening and I just wanted to make it work. Sounds good! Thanks a lot for your comments - and of course also for maintaining argyll :) Yours, Wolfgang Oertl
Wolfgang Oertl wrote: Modifying Jambase is the harder and more risky approach - changing Jamfiles is far safer and less complex. Graeme Gill.
Am Wed, 13 May 2015 14:49:12 +1000 schrieb Graeme Gill <graeme@argyllcms.com>: On the other hand, there are many Jamfiles, and just one Jambase file, so if the latter could be adapted to support both build modes, it would probably be easier to maintain. The Jamfile could specify what should be a regular .a library, and what can be either. It probably has been discussed before, but I can't help mentioning it. I'm not quite sure what the real advantages of Jam are over gmake, which is widely deployed, very portable in conjunction with the autotools package, and everybody knows it, so it is easier to maintain. No need for a 100k+ Jambase file that provides portability, which certainly fails now with the shared library patch I concocted. Just my 2¢. Cheers, Wolfgang Oertl
Wolfgang Oertl wrote: The Jambase is not project specific, so in modifying it, you are affecting all projects that use that Jambase, not just ArgyllCMS. To make changes that affect just the ArgyllCMS project, you need to to change the Jamtop and Jamfiles that are part of ArgyllCMS. Jam is platform neutral - gmake etc. are not universal (you won't find them on MSWindows). When I occasionally have to use it, I also find that autotools is extremely unreliable (constant breakage due to version churn), and I find the mish-mash of tools very difficult to understand or modify. Jam in contrast, is just a single program. Bottom line - I chose Jam as a better alternative at the time of creating ArgyllCMS, and if I was at all tempted to change to something else, it wouldn't be gmake + autotools. How big is gmake + unix tools + automake ? Graeme Gill.
Hello, upstream don't change the buildsystem since more the 3 years and was based on a oldstable release. So I close this bug. CU Jörg
Hello, upstream don't change the buildsystem since more the 3 years and was based on a oldstable release. So I close this bug. CU Jörg
Control: found -1 2.0.0+repack-1 This bug has not been fixed, it has even become worse. Argyll takes over 100M now. Thus reopening. Have you actually raised this upstream with upstream?