Bug#727691: (no subject)
hi gianfranco, On Tue, Oct 29, 2013 at 09:57:50AM +, Gianfranco Costamagna wrote: > Ok I found and fixed the problem. > > The problem was that (seems to be a fault in debian/check build), check > wasn't linked against pthread, math and time. > this commit fixed the problem > https://github.com/LocutusOfBorg/ettercap/commit/a8d67aa64ecea865971105fff1256de7ecf749cc > > I had some of this kind of problem with the switch from eglibc 2.15 to eglibc > 2.17, I had to add manually some pthread or math somewhere in the makefiles > on various debian programs, because the libraries weren't automatically > linked (I never looked deeply at this kind of issues). > > can this be fixed on check side? absolutely, there already is an open bug about this: #712140 regards robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Bug#727691: (no subject)
> Il Martedì 29 Ottobre 2013 10:23, Robert Lemmen ha > scritto: > > On Tue, Oct 29, 2013 at 08:50:05AM +, Gianfranco Costamagna wrote: >> >because of this, libcheck is shipped as a *static only* library, which >> >means you can still link against it and don't have to include > libcheck >> >*code* in your project. the static library is called liobcheck.a, and a >> >typical linker invocation involves "-static" to tell the > linker about >> >the fact that you want to link statically. >> >> Thanks, I tried, but I'm still having linking problems. >> (I don't know why travis-ci succeedes, while I have problems on my > computer > > hmm, can you tell me in detail what you are doing (i.e. linker > invocation) and what error message you are getting? > Ok I found and fixed the problem. The problem was that (seems to be a fault in debian/check build), check wasn't linked against pthread, math and time. this commit fixed the problem https://github.com/LocutusOfBorg/ettercap/commit/a8d67aa64ecea865971105fff1256de7ecf749cc I had some of this kind of problem with the switch from eglibc 2.15 to eglibc 2.17, I had to add manually some pthread or math somewhere in the makefiles on various debian programs, because the libraries weren't automatically linked (I never looked deeply at this kind of issues). can this be fixed on check side? >> Sorry I didn't undestand this part, the pourpose of check is to include > tests on a particular software right? >> >> what we do is: >> - build ettercap, >> - build tests (linked against check) >> - run tests. >> >> so check is not linked against ettercap, but only against test code, and it > isn't shipped with any installer, is just for running testsuites. >> >> Do you have any better way for running tests on ettercap project? > > no better suggestions, what you do sounds absolutely right. I just said > that because a typical reason for people wanting a .so instead of a > static lib si that they want to ship the test binary and are concerned > about the size of it. and that's just not what unit tests are for... > > Well, thanks for the explanation! > regards robert > > -- > Robert Lemmen http://www.semistable.com > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727691: (no subject)
On Tue, Oct 29, 2013 at 08:50:05AM +, Gianfranco Costamagna wrote: > >because of this, libcheck is shipped as a *static only* library, which > >means you can still link against it and don't have to include libcheck > >*code* in your project. the static library is called liobcheck.a, and a > >typical linker invocation involves "-static" to tell the linker about > >the fact that you want to link statically. > > Thanks, I tried, but I'm still having linking problems. > (I don't know why travis-ci succeedes, while I have problems on my computer hmm, can you tell me in detail what you are doing (i.e. linker invocation) and what error message you are getting? > Sorry I didn't undestand this part, the pourpose of check is to include tests > on a particular software right? > > what we do is: > - build ettercap, > - build tests (linked against check) > - run tests. > > so check is not linked against ettercap, but only against test code, and it > isn't shipped with any installer, is just for running testsuites. > > Do you have any better way for running tests on ettercap project? no better suggestions, what you do sounds absolutely right. I just said that because a typical reason for people wanting a .so instead of a static lib si that they want to ship the test binary and are concerned about the size of it. and that's just not what unit tests are for... regards robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Bug#727691: (no subject)
Il Lunedì 28 Ottobre 2013 14:16, Robert Lemmen ha scritto: hi gianfranco, > >there is indeed some reasoning behind this: the ABI (and even API) of >libcheck isn't particularily stable, arguably it wouldn't even be >desirable for a library like this to have a stable interface: the cost >of making it harder to change outweghts the benefits. > >because of this, libcheck is shipped as a *static only* library, which >means you can still link against it and don't have to include libcheck >*code* in your project. the static library is called liobcheck.a, and a >typical linker invocation involves "-static" to tell the linker about >the fact that you want to link statically. Thanks, I tried, but I'm still having linking problems. (I don't know why travis-ci succeedes, while I have problems on my computer > >please also note that it is not the target usecase to ever *ship* >anything linked against libcheck, which is the usual reason for wanting >to link against a .so. Sorry I didn't undestand this part, the pourpose of check is to include tests on a particular software right? what we do is: - build ettercap, - build tests (linked against check) - run tests. so check is not linked against ettercap, but only against test code, and it isn't shipped with any installer, is just for running testsuites. Do you have any better way for running tests on ettercap project? thanks for your answers! G. > >regards robert > > >On Fri, Oct 25, 2013 at 02:10:06PM +0100, Gianfranco Costamagna wrote: >> Hi developers, maybe do you have a rationale for this, but in ettercap we >> have recently enabled tests, and we link our tests with libcheck.so file. >> >> In debian seems to be this file is deleted upon build, as shown in rules file >> rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so.* >> rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so >> rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.la >> >> How can we link it if you delete it when building? >> >> At this moment we are using an embedded libcheck copy, but this solution >> isn't the best one. > >-- >Robert Lemmen http://www.semistable.com > > -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727691: (no subject)
hi gianfranco, there is indeed some reasoning behind this: the ABI (and even API) of libcheck isn't particularily stable, arguably it wouldn't even be desirable for a library like this to have a stable interface: the cost of making it harder to change outweghts the benefits. because of this, libcheck is shipped as a *static only* library, which means you can still link against it and don't have to include libcheck *code* in your project. the static library is called liobcheck.a, and a typical linker invocation involves "-static" to tell the linker about the fact that you want to link statically. please also note that it is not the target usecase to ever *ship* anything linked against libcheck, which is the usual reason for wanting to link against a .so. regards robert On Fri, Oct 25, 2013 at 02:10:06PM +0100, Gianfranco Costamagna wrote: > Hi developers, maybe do you have a rationale for this, but in ettercap we > have recently enabled tests, and we link our tests with libcheck.so file. > > In debian seems to be this file is deleted upon build, as shown in rules file > rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so.* > rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so > rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.la > > How can we link it if you delete it when building? > > At this moment we are using an embedded libcheck copy, but this solution > isn't the best one. -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
Bug#727691: (no subject)
Control: retitle -1 check framework library is missing the so files -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727691: (no subject)
Package: check Version: 0.9.10-5 Hi developers, maybe do you have a rationale for this, but in ettercap we have recently enabled tests, and we link our tests with libcheck.so file. In debian seems to be this file is deleted upon build, as shown in rules file rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so.* rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.la How can we link it if you delete it when building? At this moment we are using an embedded libcheck copy, but this solution isn't the best one. Thanks, Gianfranco -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
