Bug#1005887: unixodbc-dev does not contain unixodbc_conf.h
Hi Hugh, Thanks for your answer. I'm not convinced. You are telling that we must define macros to make sql.h get the right type for SQLBIGINT. Getting the right type (some alias for int64_t or a struct) is IMO something that should be done by unixodb such that the application gets a working SQLBIGINT that matches the library. That is how it used to be as long as we use unixodbc. sql.h used to do so by including the platform dependent type configuration file. As it is working now, we actually have to know which of the HAVE_* and SIZEOF_* macros we must define before including sql.h. If this is no longer how it works, do you happen to know the motivation why not? Thanks --- Jan
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
On 5/4/20 11:07 AM, Jonas Smedegaard wrote: > If perhaps your reason for fusing ABIs is that you are not a fan of > perl, then I would be happy to help write the perl code for a dh_* tool > which handles all 4 ABIs. It was a theoretical exercise. I'm not a fan of four virtual packages. One is already close to an overkill, surely at this point in time. There could be some point in two, one taking the first number and a second to join the rest or all four. The first is enough for packages that provide foreign extensions to SWI-Prolog. This allows creating Debian packages for most of the add-ons. The second is needed for saved states. Omitting the first number is possible for states that do not contain foreign extensions. It is very unlikely there will ever be a version update that changes the first number and leaves the others intact though: the stability goes down from left to right (which is why the last two are fingerprints rather than version numbers: I forgot to update them too often). Cheers --- Jan
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Lev,
On 5/3/20 6:32 PM, Lev Lamberov wrote:
Hi Jan and Jonas,
Чт 30 апр 2020 @ 20:36 Lev Lamberov :
So, my proposal is to have to following packages:
1. swi-prolog-core (with Core_system)
2. swi-prolog-core-packages (with Core_packages), depends on
swi-prolog-core
3. swi-prolog-nox (original swi-prolog-nox, but without
swi-prolog-{core,core-packages}), depends on
swi-prolog-{core,core-packages}
4. swi-prolog-x (without changes at the moment)
5. swi-prolog-java (without changes at the moment)
6. swi-prolog-bdb (without changes at the moment)
7. swi-prolog-odbc (without changes at the moment)
8. swi-prolog-doc (without changes at the moment)
9. swi-prolog-test (without changes at the moment)
10. swi-prolog, depends on swi-prolog-{nox,x} as we have now
11. swi-prolog-full, depends on swi-prolog and
swi-prolog-{java,odbc,bdb}, that is all swi-prolog packages (maybe
except swi-prolog-test)
I've just uploaded 8.1.30 to experimental. swi-prolog source package
builds 11 packages as in the quotation above. swi-prolog-core provides
virtual package swi-prolog-abi-$(swi-prolog:ABI), the value of
$(swi-prolog:ABI) is based on the output of swipl --abi_version and
massaged as follows:
$(shell LD_LIBRARY_PATH=debian/swi-prolog-core/usr/lib
debian/swi-prolog-core/usr/bin/swipl --abi-version | sed 's/swipl-abi//' | tr
-d '-')
I suggest 's/.*-abi-//' as the first part is basically flexible and may
vary with the name of SWI-Prolog. Personally I'd also be in favor of
not deleting the '-'. Jonas doesn't see the need for that either.
There is a logical structure in that. If you do it really correctly
you actually would have four virtual packages. eye, not relying on
foreign extensions (except bundled with SWI-Prolog) could than drop
dependency on this part. This is mostly theory though as this is
the most stable of the binary interfaces.
Cheers --- Jan
That is, for 8.1.30+dfsg-1 it gives 267792e14f8de23899e, since the
output of swipl --abi_version is swipl-abi-2-67-792e14f8-de23899e. So,
other packages may depend on swi-prolog-abi-267792e14f8de23899e in case
they need this particular version of ABI.
Jonas, I did some tweaks to dependencies, so this part should be cleaner
now.
Also, I looked into the eye package. It need pcre swi-prolog package,
which is in swi-prolog-nox (as before), so you still need to at least
Build-Depend on it.
Cheers!
Lev Lamberov
Bug#958419: swi-prolog 8.1.29 in Debian
Hi Lev, Jonas, I've uploaded 8.1.30. We should be getting really close to 8.2 now. There are a couple of outstanding issues, notably for the development tools. Cheers --- Jan On 4/30/20 3:13 PM, Lev Lamberov wrote: Sure, that's what we need. Thanks, Jan!
Bug#959027: Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Lev, On 4/30/20 3:10 PM, Lev Lamberov wrote: > Recently I was (again!) approached by some embedded developers who asked > to provide Core_system as a separate package and try to break > swi-prolog-nox into several smaller packages. > > Currently, I'm thinking about breaking it into swi-prolog-core > (containing Core_system), swi-prolog-core-packages (containing > Core_packagse; depends on swi-prolog-core) and swi-prolog-nox > (containing other components from the original swi-prolog-nox; depends > on swi-prolog-core and swi-prolog-core-packages). What do you think > about it? As long as swi-prolog-nox still provides a useable Prolog system I'm happy. I would go with Jonas in that case though and have yet another basic package that just contains the shared object and possibly the main executable and boot file (swipl.prc) Just the shared object is enough to create runtimes when using --stand-alone as this creates a file that starts with the swipl executable. Adding the swipl executable to the base package allows to start the state with some option and makes the state smaller (but not much, `swipl` is really short). Adding the boot.prc file adds only 90Kb and actually allows running Prolog. Without libraries, but you could distribute the essentials with some application as .pl or .qlf files. If we rethink from the start, my ideal is that "swi-prolog" creates a pretty much complete installation, including xpce (gui, ide). Yes, there are quit a few dependencies, but virtually every desktop installation has most of these installed anyway. Then we can have some hierarchy below that. Some parts are clear, but the real dependencies between the various packages is largely unknown and easily varies between versions. If you are interested I could come up with some meaningful splits. Bottom line should be just the real core (as above), which is enough to run saved states. You than have two options for saved states relying on foreign packages: include the package in the saved state or install the package. Cheers --- Jan > > Cheers! > Lev >
Bug#958419: swi-prolog 8.1.29 in Debian
On 4/30/20 2:50 PM, Jonas Smedegaard wrote: Quoting Lev Lamberov (2020-04-30 14:40:53) Чт 30 апр 2020 @ 14:06 Jan Wielemaker : On 4/30/20 1:41 PM, Jonas Smedegaard wrote: I think we can use the format almost as-is - just replacing the leading "swipl-" with "swi-prolog-abi-". I think adding "abi" makes sense. I can replace "swipl" with the package name, which is "swi-prolog" for Debian. I'm thinking about something like as follows: Provides: swi-prolog-abi-$(swipl:ABI) where $(swipl:ABI) will be set in d/rules in override_dh_gencontrol target, so actually it doesn't matter what is the original output of swipl --abi_version, since we have sed and other tools to make it as we like. What do you think, Jonas? I agree with Lev. That is what I tried to say above as well (that we can _take_ it as-is and will need to massage it only slightly), but I see now that it can just as easily be read as meaning the opposite (that we would need a slightly different format). So to (try) clarify: I think it is *perfect* usable for Debian that upstream code emits "swipl-2-67-792e14f8-de23899e" when asked for its ABI. I did change it now to be $SWIPL_PKG_NAME-abi-*, where the default SWIPL_PKG_NAME is derived from $SWIPL_INSTALL_DIR if it contains something usable and "swipl" otherwise (some installations set this to "."). I don't think you care too much. Unless there is a real need to change I'll keep it that way. It is nicely informative. If you just want the numbers you can delete `^.*-abi-`. Cheers --- Jan Sorry for the confusion. - Jonas
Bug#958419: swi-prolog-nox: compiler and runtime execution shipped in same package
Hi Jonas, In theory we could have a package that merely contains /usr/bin/swipl and /usr/lib/libswipl.so.8.2.0. That is enough to run saved states (provided they have been built such that no dependencies need to be loaded at runtime) and is indeed a lot smaller than swi-prolog-nox. Possibly bundle these two as swi-prolog-runtime and make swi-prolog-nox depend on it? A small problem is that running `swipl` will result in a big ugly error message that it cannot find its startup resources. One could add boot.prc to the runtime package which would allow running Prolog (but without any library). I'm pretty neutral in this. Eye is for the time being the only use case, but who knows there will be more :) --- Jan
Bug#958419: swi-prolog 8.1.29 in Debian
On 4/30/20 1:41 PM, Jonas Smedegaard wrote: I think we can use the format almost as-is - just replacing the leading "swipl-" with "swi-prolog-abi-". I think adding "abi" makes sense. I can replace "swipl" with the package name, which is "swi-prolog" for Debian. --- Jan
Bug#958419: swi-prolog 8.1.29 in Debian
Hi Jonas, On 4/28/20 5:26 PM, Jonas Smedegaard wrote: Quoting Jan Wielemaker (2020-04-28 16:56:30) That is worth a try. I guess that implies that generating SWI-Prolog (as package) also generates this hash. What kind of support would be needed from SWI-Prolog to make this work? Some script/command to create this hash for a particular system? Thanks for your interest in this challenge :-) Yes, if ABI is computed during build then what would be helpful is to extend that to expose the computed ABI as a single string. Maybe add it as an additional note in output of "swipl --version"? Or if possible to (re)compute at runtime then just document that, for us distribution maintainers to integrate into our packaging routines. I think I cover this nicely now: janw (linux; master) 68_> swipl --abi_version swipl-2-67-792e14f8-de23899e There is a section in the docs explaining the various binary ABIs and what aspects rely on them. There is a new function PL_version() in the C api that can be used to query the versions individually. The above says: - Backward compatibility version of the foreign interface is 2 - Saved state file format can be loaded when not older than 67 - 792e14f8 is a fingerprint for the C-defined foreign predicate signatures. - de23899e is a fingerprint of the VM instructions and their signatures. Does this adequately solve your problems? Do you see other requirements? Can you test on this, or would you rather wait for an official 8.1.30? I can create that now if that is useful to speedup stabilizing stuff to get at 8.2.0. Thanks --- Jan
Bug#958419: swi-prolog 8.1.29 in Debian
Hi Jonas, On 4/28/20 4:42 PM, Jonas Smedegaard wrote: Hi Jan, Quoting Jan Wielemaker (2020-04-28 16:12:32) A saved state makes sense for this scenario. Now I do not really understand what the problem is. The eye package depends on some exact version of SWI-Prolog, but it is not uncommon for one package to require some specific version of a library, no? Is the real problem that we cannot two versions of SWI-Prolog installed side-by-side, so eye can depend on a specific version? That can be fixed using -DSWIPL_VERSIONED_DIR=ON to the CMake configure, which installs swi-prolog in /usr/lib/swi-prolog-. Now we get the problem that Debian likes -DSWIPL_INSTALL_IN_LIB=ON, installing the shared object in /usr/lib, but this too should be versioned, no? The above seems one way out (but probably requires some work). Another is to have the post-install script of eye create the saved state. Finally, we could use caching by having eye.sh test for a state at some cache location (e.g., ~/.cache/swi-prolog/states/eye.pvm) and using this if available or first call swipl to create the saved state. Would be nice to have an overall preferred solution for package managers to deal with SWI-Prolog saved states. I think all three above are viable, each with pros and cons and no clear winner. The problem - which I consider a minor one - is to know for certain when it is needed to regenerate an image. I prefer that the binary package for eye contains only the generated image (i.e. the eye source to generate that image is part of the Debian _source_ package but not included in the _binary_ *.deb). What I would then see as ideal would be if the binary package could know which exact ABI of SWI Prolog it was tied to, so that it was known when it was needed to regenerate the package. You mentioned in a precviously quoted email that the ABI consist of two parts, one of them being a hash of a VM and the other being a set of variables. I would gues that an ABI could then be some chars of the VM hash + some chars of a hash of those variables. Debian packaging of Asterisk and uWSGI uses such ABI hash towards third party plugins, to alow them to be rebuilt as infrequently as possible. See e.g. https://packages.debian.org/buster/uwsgi-plugin-php and https://packages.debian.org/buster/asterisk-espeak (notice they depend only indirectly on uwsgi/asterisk through a virtual ABI package name). That is worth a try. I guess that implies that generating SWI-Prolog (as package) also generates this hash. What kind of support would be needed from SWI-Prolog to make this work? Some script/command to create this hash for a particular system? Let me emphasize that I do *not* consider this an important issue: Makes sense if you simply consider your upstream official release version _is_ the "ABI", and if we in Debian choose to carry a patch which breaks that "ABI" then that's our headache, not yours. In practice, surely for now, this is just as good. The next version packaged with Debian is typically the next stable release, which almost always breaks full compatibility of the ABI wrt the previous stable. It would make sense if we could establish a working series of patches on a stable release that is guaranteed not to break the ABI. I'm afraid the project never managed to make this work. Projects that must rely on a stable version typically backport relevant fixes themselves or found some other way to ensure access to a version that is (for the project) the right mix between stability, features and bugs. Cheers --- Jan
Bug#958419: swi-prolog 8.1.29 in Debian
Hi Jos, Lev, Jonas, A saved state makes sense for this scenario. Now I do not really understand what the problem is. The eye package depends on some exact version of SWI-Prolog, but it is not uncommon for one package to require some specific version of a library, no? Is the real problem that we cannot two versions of SWI-Prolog installed side-by-side, so eye can depend on a specific version? That can be fixed using -DSWIPL_VERSIONED_DIR=ON to the CMake configure, which installs swi-prolog in /usr/lib/swi-prolog-. Now we get the problem that Debian likes -DSWIPL_INSTALL_IN_LIB=ON, installing the shared object in /usr/lib, but this too should be versioned, no? The above seems one way out (but probably requires some work). Another is to have the post-install script of eye create the saved state. Finally, we could use caching by having eye.sh test for a state at some cache location (e.g., ~/.cache/swi-prolog/states/eye.pvm) and using this if available or first call swipl to create the saved state. Would be nice to have an overall preferred solution for package managers to deal with SWI-Prolog saved states. I think all three above are viable, each with pros and cons and no clear winner. Cheers --- Jan On 4/28/20 3:11 PM, Jos De Roo wrote: > Hi Lev, > > Yes indeed, eye is using a saved state to have it started 10 times > faster than normal: > > $ time swipl -x /opt/eye/lib/eye.pvm -- --version > eye --version > EYE v20.0423.1748 josd > SWI-Prolog version 8.1.29 > starting 31 [msec cputime] 37 [msec walltime] > > real 0m0.041s > user 0m0.037s > sys 0m0.004s > > $ time swipl -f /opt/eye/src/eye.pl <http://eye.pl> -g main -- --version > eye --version > EYE v20.0423.1748 josd > SWI-Prolog version 8.1.29 > starting 344 [msec cputime] 393 [msec walltime] > > real 0m0.401s > user 0m0.343s > sys 0m0.015s > > and this is quite crucial as eye is typically used as a short running > process > which is getting data/rules/query from the web, returning answers/proofs > for the query and then closing the process as the internal state (e.g. the > deductive closure of the forward reasoning run) is of no use to the next > run. > > Kind regards, > Jos > > -- https://josd.github.io/ <http://josd.github.io/> > > > On Tue, Apr 28, 2020 at 1:30 PM Lev Lamberov <mailto:dogs...@debian.org>> wrote: > > Вт 28 апр 2020 @ 13:11 Jan Wielemaker <mailto:j.wielema...@vu.nl>>: > > > Hi Lev, > > > > I most wanted to get Jos in the loop as the developer of eye. > Packagers > > working together with developers/maintainers saves a lot of work :) > > Awww... so, CCing Jos De Roo. > > Jos, could you be so kind to take a look at the #958561 Debian bug > report concerning swi-prolog and eye. You can find it there: > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=958561 > > > On 4/28/20 12:49 PM, Lev Lamberov wrote: > >> Hi Jan, > >> > >> Вт 28 апр 2020 @ 11:22 Jan Wielemaker <mailto:j.wielema...@vu.nl>>: > >> > >>> Hi Lev, Jos, > >>> > >>> For Jos, the problem is that eye installs as a SWI-Prolog saved > state, > >>> which is highly version dependent and this is difficult to deal > with > >>> given the Debian dependency and upgrade policy (Lev, hope this > is the > >>> right summary, please correct if not). > >>> > >>> I has a little look at eye and I wonder why we need the state. > eye.pl <http://eye.pl> > >>> isn't that big and loads in about 0.12 sec on my machine. > Without a > >>> state, eye seems to run easily using the simple script > >>> > >>> swipl -g main /path/to/eye.pl <http://eye.pl> "$@" > >>> > >>> Or by installing eye.pl <http://eye.pl> as the actual > executable and start is using > >>> > >>> #!/bin/env swipl > >>> > >>> and use somewhere in the file > >>> > >>> :- initialization(main,main). > >>> > >>> Would it make sense to go this route? If not, why not? Is the > >>> somewhat longer startup time an issue? > >>> > >>> Thanks --- Jan > >> > >> I'm sending your message to the bug report and to Jonas Smedegaard. > >> Please, send your further replies to 958...@bugs.debian.org > <mailto:958...@bugs.debian.org> > >> > >> Cheers! > >> Lev >
Bug#958419: swi-prolog 8.1.29 in Debian
On 4/28/20 5:06 PM, Lev Lamberov wrote: Hi Jan, Вт 28 апр 2020 @ 16:56 Jan Wielemaker : Debian packaging of Asterisk and uWSGI uses such ABI hash towards third party plugins, to alow them to be rebuilt as infrequently as possible. See e.g. https://packages.debian.org/buster/uwsgi-plugin-php and https://packages.debian.org/buster/asterisk-espeak (notice they depend only indirectly on uwsgi/asterisk through a virtual ABI package name). That is worth a try. I guess that implies that generating SWI-Prolog (as package) also generates this hash. What kind of support would be needed from SWI-Prolog to make this work? Some script/command to create this hash for a particular system? Let me emphasize that I do *not* consider this an important issue: Makes sense if you simply consider your upstream official release version _is_ the "ABI", and if we in Debian choose to carry a patch which breaks that "ABI" then that's our headache, not yours. In practice, surely for now, this is just as good. The next version packaged with Debian is typically the next stable release, which almost always breaks full compatibility of the ABI wrt the previous stable. Do you mean stable branches (like 8.0.x vs. 8.2.x) or revisions of a given stable branch (8.0.1 vs. 8.0.2 vs. 8.0.3)? I personally would expect no changes of ABI in a given stable branch and I think it is what is typically expected. I mean no new features => no ABI change, no? In most cases patch levels should not affect the ABI, but we have not always been completely strict in this. A bug that requires an ABI change (which happens) can happen in a patch level release. The only real guarantee is that source code is fully compatible between patch levels in the stable branch. We try to maintain as much as possible binary compatibility and 99% of the cases we succeed in that. Cheers --- Jan Cheers! Lev
Bug#958419: swi-prolog 8.1.29 in Debian
Hi Lev, I most wanted to get Jos in the loop as the developer of eye. Packagers working together with developers/maintainers saves a lot of work :) Cheers --- Jan On 4/28/20 12:49 PM, Lev Lamberov wrote: Hi Jan, Вт 28 апр 2020 @ 11:22 Jan Wielemaker : Hi Lev, Jos, For Jos, the problem is that eye installs as a SWI-Prolog saved state, which is highly version dependent and this is difficult to deal with given the Debian dependency and upgrade policy (Lev, hope this is the right summary, please correct if not). I has a little look at eye and I wonder why we need the state. eye.pl isn't that big and loads in about 0.12 sec on my machine. Without a state, eye seems to run easily using the simple script swipl -g main /path/to/eye.pl "$@" Or by installing eye.pl as the actual executable and start is using #!/bin/env swipl and use somewhere in the file :- initialization(main,main). Would it make sense to go this route? If not, why not? Is the somewhat longer startup time an issue? Thanks --- Jan I'm sending your message to the bug report and to Jonas Smedegaard. Please, send your further replies to 958...@bugs.debian.org Cheers! Lev
Bug#793211: swi-prolog 7.2 breaks the ppl prolog bindings
Hi Eugeniy, On 08/14/2015 10:15 AM, Eugeniy Meshcheryakov wrote: Hi Jan, The test suite was disabled in ppl so swi-prolog did migrate to testing. I see Ubuntu also got this version. So it is not so bad anymore. Great! It would be good to fix this some time anyway. I may look at it this weekend. If I can help, just ask. There is a 7.2.3 ready to be created. I considered creating it yesterday, but decided to see whether we could resolve this first. Cheers --- Jan
Bug#793211: swi-prolog 7.2 breaks the ppl prolog bindings
Dear all, I've returned from holidays. This issue seems a show stopper getting SWI-Prolog 7.2 into Debian and its offspring. What is the status? Can I help? Concerning the build fails on amd64, I guess I can reproduce this. Cheers -- Jan On 07/23/2015 09:18 PM, Eugeniy Meshcheryakov wrote: Hello Jan, I've got the following bug report from a Debian developer. Do you have any idea how to fix it? This issue prevents swi-prolog from migrating to Debian testing. The original bug report for PPL is available here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787486 This bug report is archived here (also contains the log file): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793211 Regards, Eugeniy Meshcheryakov 22 липня 2015 о 15:09 +0200 Matthias Klose написав(-ла): Package: src:swi-prolog Version: 7.2.0-2 Severity: important swi-prolog 7.2 breaks the ppl prolog bindings, such that ppl has to be built with -fpermissive. However running the tests reveals that these are then broken. swi-prolog 6 works fine. See #787486 for the ppl issue. [...] Making check in Prolog make[4]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' /usr/bin/make check-recursive make[5]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' Making check in . make[6]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' make[6]: Nothing to be done for 'check-am'. make[6]: Leaving directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' Making check in tests make[6]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' /usr/bin/make check-local make[7]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' /usr/bin/m4 --prefix-builtin -I../.. \ -I. -I./.. -I./../.. \ ./ppl_interface_generator_prolog_generated_test_pl.m4 \ ppl_prolog_generated_test_blob ../../../utils/cm_cleaner.sh ./ppl_prolog_generated_test_blob ../../../utils/cm_splitter.sh ./ppl_prolog_generated_test_blob rm -f ppl_prolog_generated_test_blob echo timestamp ppl_prolog_generated_test.stamp make[7]: Leaving directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' make[6]: Leaving directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' Making check in SWI make[6]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/SWI' /usr/bin/make ppl_pl pl_clpq pl_clpq2 make[7]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/SWI' x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../interfaces -I../../../interfaces/Prolog -I/interfaces/Prolog -I../../../src -I/usr/lib/swi-prolog/include -I/usr/include/pl -D_FORTIFY_SOURCE=2 -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall -MT ppl_pl.o -MD -MP -MF .deps/ppl_pl.Tpo -c -o ppl_pl.o ppl_pl.cc x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../interfaces -I../../../interfaces/Prolog -I/interfaces/Prolog -I../../../src -I/usr/lib/swi-prolog/include -I/usr/include/pl -D_FORTIFY_SOURCE=2 -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall -MT pl_clpq.o -MD -MP -MF .deps/pl_clpq.Tpo -c -o pl_clpq.o pl_clpq.cc mv -f .deps/ppl_pl.Tpo .deps/ppl_pl.Po mv -f .deps/pl_clpq.Tpo .deps/pl_clpq.Po /usr/bin/swipl-ld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++ -ld x86_64-linux-gnu-g++ \ -ld-options`echo '' -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall | tr /` \ -o ppl_pl .libs/libppl_swiprolog.a ppl_pl.o \ -L../../../src/.libs \ -lppl -lgmpxx -lgmp /usr/bin/swipl-ld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++ -ld x86_64-linux-gnu-g++ \ -ld-options`echo '' -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall | tr /` \ -o pl_clpq .libs/libppl_swiprolog.a pl_clpq.o \ ./pl_clpq.pl ./../tests/clpq.pl \ -L../../../src/.libs \ -lppl -lgmpxx -lgmp /usr/bin/swipl-ld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++ -ld x86_64-linux-gnu-g++ \ -ld-options`echo '' -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall | tr /` \ -o pl_clpq2 .libs/libppl_swiprolog.a pl_clpq.o \ ./pl_clpq.pl ./../tests/clpq2.pl \ -L../../../src/.libs \ -lppl -lgmpxx -lgmp Warning: /scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests/clpq.pl:208: Singleton variable in branch: File_Name Warning: /scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests/clpq2.pl:293: Singleton variable in branch: File_Name Warning:
Bug#793211: swi-prolog 7.2 breaks the ppl prolog bindings
Hi Eugeniy, No real clue. The stacktrace is definitely completely broken, I guess because too much symbol data is missing. I guess the simplest step is to make sure the compile flags include -g and possibly drop -O2 and symbols are not stripped. Then we might get a stacktrace that indicates the real problem. The type of error is typically caused by calls from C to Prolog that ignore the (FALSE) return value. The vital API functions do have the gcc attribute that causes gcc to warn on ignored return values, so inspecting the build log may give a clue. I can't do much right now as I'm travelling with only a small chromebook If you manage to produce a proper stack trace, please sent it. Might take a few days for me to respond. I'm back at the office as of August 10. Cheers --- Jan On 07/23/15 21:18, Eugeniy Meshcheryakov wrote: Hello Jan, I've got the following bug report from a Debian developer. Do you have any idea how to fix it? This issue prevents swi-prolog from migrating to Debian testing. The original bug report for PPL is available here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=787486 This bug report is archived here (also contains the log file): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=793211 Regards, Eugeniy Meshcheryakov 22 липня 2015 о 15:09 +0200 Matthias Klose написав(-ла): Package: src:swi-prolog Version: 7.2.0-2 Severity: important swi-prolog 7.2 breaks the ppl prolog bindings, such that ppl has to be built with -fpermissive. However running the tests reveals that these are then broken. swi-prolog 6 works fine. See #787486 for the ppl issue. [...] Making check in Prolog make[4]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' /usr/bin/make check-recursive make[5]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' Making check in . make[6]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' make[6]: Nothing to be done for 'check-am'. make[6]: Leaving directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog' Making check in tests make[6]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' /usr/bin/make check-local make[7]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' /usr/bin/m4 --prefix-builtin -I../.. \ -I. -I./.. -I./../.. \ ./ppl_interface_generator_prolog_generated_test_pl.m4 \ ppl_prolog_generated_test_blob ../../../utils/cm_cleaner.sh ./ppl_prolog_generated_test_blob ../../../utils/cm_splitter.sh ./ppl_prolog_generated_test_blob rm -f ppl_prolog_generated_test_blob echo timestamp ppl_prolog_generated_test.stamp make[7]: Leaving directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' make[6]: Leaving directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/tests' Making check in SWI make[6]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/SWI' /usr/bin/make ppl_pl pl_clpq pl_clpq2 make[7]: Entering directory '/scratch/packages/tmp/ppl-1.1/interfaces/Prolog/SWI' x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../interfaces -I../../../interfaces/Prolog -I/interfaces/Prolog -I../../../src -I/usr/lib/swi-prolog/include -I/usr/include/pl -D_FORTIFY_SOURCE=2 -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall -MT ppl_pl.o -MD -MP -MF .deps/ppl_pl.Tpo -c -o ppl_pl.o ppl_pl.cc x86_64-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I../../.. -I../../../interfaces -I../../../interfaces/Prolog -I/interfaces/Prolog -I../../../src -I/usr/lib/swi-prolog/include -I/usr/include/pl -D_FORTIFY_SOURCE=2 -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall -MT pl_clpq.o -MD -MP -MF .deps/pl_clpq.Tpo -c -o pl_clpq.o pl_clpq.cc mv -f .deps/ppl_pl.Tpo .deps/ppl_pl.Po mv -f .deps/pl_clpq.Tpo .deps/pl_clpq.Po /usr/bin/swipl-ld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++ -ld x86_64-linux-gnu-g++ \ -ld-options`echo '' -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall | tr /` \ -o ppl_pl .libs/libppl_swiprolog.a ppl_pl.o \ -L../../../src/.libs \ -lppl -lgmpxx -lgmp /usr/bin/swipl-ld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++ -ld x86_64-linux-gnu-g++ \ -ld-options`echo '' -g -O2 -frounding-math -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -Wall -g -fpermissive -W -Wall | tr /` \ -o pl_clpq .libs/libppl_swiprolog.a pl_clpq.o \ ./pl_clpq.pl ./../tests/clpq.pl \ -L../../../src/.libs \ -lppl -lgmpxx -lgmp /usr/bin/swipl-ld -pl /usr/bin/swipl -cc x86_64-linux-gnu-gcc -c++ x86_64-linux-gnu-g++ -ld x86_64-linux-gnu-g++ \ -ld-options`echo ''
Bug#606250: System map of 2.6.32-5-amd64 does not match kernel
Dear Ben, Thanks for looking into this. On Wed, 2010-12-08 at 01:30 +, Ben Hutchings wrote: On Wed, 2010-12-08 at 00:11 +, Ben Hutchings wrote: On Tue, 2010-12-07 at 21:13 +0100, Jan Wielemaker wrote: [...] Looks like a trivial bug, but I cannot find a report that indicates it has been filed before. Is there a way to fix this without recompiling the kernel from scratch myself? This is a bug in procps. It's relying on some version information which is only present in System.map if the kernel was configured without CONFIG_KALLSYMS set. Actually this is not so clear. The error message ps shows when you set PS_SYSTEM_MAP is incorrect, but then ps shouldn't even need System.map when the kernel is configured with CONFIG_KALLSYMS! This is just the Debian testing generic kernel for AMD64. I see there is an entry /proc/kallsyms that exports the symbols. That looks just fine. However, wchan cannot be provided when the 'omit frame pointer' optimisation is used in the kernel. We enable that optimisation on x86 kernels, and have done for some time. Hmmm. I though omit frame pointer only makes sense on x86. This is AMD64. When I run ps under strace, it neither tries to open /proc/kallsyms, nor /boot/System.map*!? Regards --- Jan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#606250: System map of 2.6.32-5-amd64 does not match kernel
Package: linux-image Version: 2.6.32-5-amd64 Hi, Trying to debug ocfs2 issues, I noticed that the system.map file doesn't match the kernel in the latest Squeeze version. Here are my findings: # dpkg -S /boot/System.map-2.6.32-5-amd64 linux-image-2.6.32-5-amd64: /boot/System.map-2.6.32-5-amd64 # dpkg -S /boot/vmlinuz-2.6.32-5-amd64 linux-image-2.6.32-5-amd64: /boot/vmlinuz-2.6.32-5-amd64 So, both come from the same package. The (2) machines have been rebooted after the last kernel upgrade. But ps -o pid,wchan=WIDE-WCHAN-COLUMN only gives - or ? as wchan. Telling it explicitly which map to use gives: # PS_SYSTEM_MAP=/boot/System.map-2.6.32-5-amd64 ps -o pid,wchan=WIDE-WCHAN-COLUMN Warning: /boot/System.map-2.6.32-5-amd64 has an incorrect kernel version. PID WIDE-WCHAN-COLUMN 18887 - Looks like a trivial bug, but I cannot find a report that indicates it has been filed before. Is there a way to fix this without recompiling the kernel from scratch myself? Thanks --- Jan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
