Re: [Cocci] make install broken
Michael Stefaniuc: > But it isn't working when I have a symlink to spatch. This surprises me because this is precisely what 82a6a045 is supposed to fix, and your version 3ba77b3 includes it. I suppose it is because your shell does not define the environment variable "_" to the path of the running executable. I just pushed on GitHub a more portable way for determining the path of the executable relying on proc_pidpath. Thank you for the report. -- Thierry Martinez. - Original Message - > From: "Michael Stefaniuc" > To: "Julia Lawall" > Cc: cocci@systeme.lip6.fr > Sent: Friday, October 6, 2017 9:03:44 PM > Subject: Re: [Cocci] make install broken > > On 10/06/2017 04:04 PM, Julia Lawall wrote: > > The makefile issues are perhaps now resolved. > Looks better as the missing stuff is installed. > But it isn't working when I have a symlink to spatch. > > My workflow: > > VERSION=`git describe` > ./configure --prefix=/usr/local/packages/coccinelle-$VERSION > make > make install > cd /usr/local/bin > ln -sf ../packages/coccinelle-$VERSION/bin/* . > > spatch foo.cocci foo.c > warning: Can't find macro file: ./../lib/coccinelle/standard.h > init_defs: ./macros > warning: Can't find default iso file: ./../lib/coccinelle/standard.iso > Python error: No module named 'coccilib' > > Using an absolute symbolic link doesn't works either. > Using an absolute PATH to spatch makes it work: > /usr/local/packages/coccinelle-1.0.6-328-g3ba77b3/bin/spatch foo.cocci foo.c > > coccinelle-1.0.6-179-g058cb06 is the last version that I have compiled > and works with the symlinks. > > No clue is there is something similar in OCaml but under perl there is > the handy FindBin module (FindBin::RealBin) to find the real location of > the binary. > > bye > michael > > > > > julia > > > > On Tue, 3 Oct 2017, Michael Stefaniuc wrote: > > > >> Hello, > >> > >> while my Makefile patch lets make install finish a lot of stuff is > >> missing: > >> spatch foo.cocci foo.c > >> warning: Can't find macro file: ./../lib/coccinelle/standard.h > >> warning: Can't find default iso file: ./../lib/coccinelle/standard.iso > >> Python error: No module named 'coccilib' > >> > >> Only this stuff gets installed: > >> find /usr/local/packages/coccinelle-1.0.6-318-g0bf5304/ > >> /usr/local/packages/coccinelle-1.0.6-318-g0bf5304/ > >> /usr/local/packages/coccinelle-1.0.6-318-g0bf5304/bin > >> /usr/local/packages/coccinelle-1.0.6-318-g0bf5304/bin/spatch > >> /usr/local/packages/coccinelle-1.0.6-318-g0bf5304/bin/spgen > >> /usr/local/packages/coccinelle-1.0.6-318-g0bf5304/lib > >> /usr/local/packages/coccinelle-1.0.6-318-g0bf5304/lib/coccinelle > >> /usr/local/packages/coccinelle-1.0.6-318-g0bf5304/lib/coccinelle/dllpyml_stubs.so > >> /usr/local/packages/coccinelle-1.0.6-318-g0bf5304/etc > >> /usr/local/packages/coccinelle-1.0.6-318-g0bf5304/etc/bash_completion.d > >> /usr/local/packages/coccinelle-1.0.6-318-g0bf5304/etc/bash_completion.d/spatch > >> > >> > >> bye > >> michael > >> ___ > >> Cocci mailing list > >> Cocci@systeme.lip6.fr > >> https://systeme.lip6.fr/mailman/listinfo/cocci > >> > > ___ > Cocci mailing list > Cocci@systeme.lip6.fr > https://systeme.lip6.fr/mailman/listinfo/cocci > ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] make install broken
I wrote:> I just pushed on GitHub a more portable way for determining the path of theexecutable relying on proc_pidpathI just noticed that you will need the libproc-dev package from your distribution to compile (Debian or Ubuntu, name on other distribution may vary). I will update install.txt and provide a fallback if the function is not available (probably by reading /proc/self/exe if it exists, otherwise by considering "_" as before).Thank you for the report.-- Thierry.___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] make install broken
Hello Thierry, On 10/11/2017 03:42 PM, Thierry Martinez wrote: > I wrote: >> I just pushed on GitHub a more portable way for determining the path > of the > executable relying on proc_pidpath > > I just noticed that you will need the libproc-dev package from your there is no such thing in Fedora. I found a procps-ng-devel but that doesn't provide libproc.h. > distribution to compile (Debian or Ubuntu, name on other distribution I'm checking Debian but cannot find a libproc there either: https://packages.debian.org/search?keywords=libproc The libproc-* is for perl. There are libprocps packages but the .h files in those seem to match what Fedora has in procps-ng-devel. A quick search finds libproc.h on github but that has an Apple copyright in it. It's basically this one: https://opensource.apple.com/source/xnu/xnu-2422.1.72/libsyscall/wrappers/libproc/libproc.h.auto.html > may vary). I will update install.txt and provide a fallback if the > function is not available (probably by reading /proc/self/exe if it > exists, otherwise by considering "_" as before). > > Thank you for the report. > -- > Thierry. > bye micheal ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] make install broken
Hello Thierry, On 10/11/2017 03:28 PM, Thierry Martinez wrote: > Michael Stefaniuc: >> But it isn't working when I have a symlink to spatch. > > This surprises me because this is precisely what 82a6a045 is supposed to fix, > and your version 3ba77b3 includes it. > > I suppose it is because your shell does not define the environment variable > "_" to the path of the running executable. my shell (GNU bash, version 4.3.43(1)) does show the executable in $_ but that is the symlink and not the real path to the executable. luna:~$ cd luna:~$ echo -e '#!/bin/bash\necho $_' > foo.sh luna:~$ chmod a+x foo.sh luna:~$ ln -s ../foo.sh bin/foo.sh luna:~$ ./foo.sh ./foo.sh luna:~$ bin/foo.sh bin/foo.sh luna:~$ foo.sh /home/michi/bin/foo.sh bye michael > > I just pushed on GitHub a more portable way for determining the path of the > executable relying on proc_pidpath. > > Thank you for the report. > ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] make install broken
Hello, Michael. Michael: > A quick search finds libproc.h on github but that has an Apple copyright > in it. It's basically this one: > https://opensource.apple.com/source/xnu/xnu-2422.1.72/libsyscall/wrappers/libproc/libproc.h.auto.html Oops, sorry. I was confused by this (old) package: https://pkgs.org/download/libproc-dev It should be fixed now (by using /proc/self/exe if available, or the environment variable _). > my shell (GNU bash, version 4.3.43(1)) does show the executable in $_ > but that is the symlink and not the real path to the executable. Yes, but spatch should have resolved the symlink. Anyway, I changed the code to use realpath, which should be more reliable (the code before only resolved symlinks on the executable file, without considering parent directories). Sorry for the wrong commit! -- Thierry. - Original Message - > From: "Michael Stefaniuc" > To: "Thierry Martinez" > Cc: cocci@systeme.lip6.fr > Sent: Wednesday, October 11, 2017 9:26:57 PM > Subject: Re: [Cocci] make install broken > > Hello Thierry, > > On 10/11/2017 03:28 PM, Thierry Martinez wrote: > > Michael Stefaniuc: > >> But it isn't working when I have a symlink to spatch. > > > > This surprises me because this is precisely what 82a6a045 is supposed to > > fix, > > and your version 3ba77b3 includes it. > > > > I suppose it is because your shell does not define the environment variable > > "_" to the path of the running executable. > my shell (GNU bash, version 4.3.43(1)) does show the executable in $_ > but that is the symlink and not the real path to the executable. > > luna:~$ cd > luna:~$ echo -e '#!/bin/bash\necho $_' > foo.sh > luna:~$ chmod a+x foo.sh > luna:~$ ln -s ../foo.sh bin/foo.sh > luna:~$ ./foo.sh > ./foo.sh > luna:~$ bin/foo.sh > bin/foo.sh > luna:~$ foo.sh > /home/michi/bin/foo.sh > > bye > michael > > > > > I just pushed on GitHub a more portable way for determining the path of the > > executable relying on proc_pidpath. > > > > Thank you for the report. > > > > ___ Cocci mailing list Cocci@systeme.lip6.fr https://systeme.lip6.fr/mailman/listinfo/cocci
Re: [Cocci] prinkt specifiers
On Wed, Oct 11, 2017 at 07:27:43AM +0200, Julia Lawall wrote:
>
>
> On Wed, 11 Oct 2017, Tobin C. Harding wrote:
>
> > Hi,
> >
> > Is it possible to craft a coccinelle script to find and replace calls (in
> > the kernel) that are
> > printing pointers using %x.
> >
> > Perhaps we could easily catch the calls that are casting the pointer within
> > argument list, for example
> >
> > pr_info("x: %llx\n", (unsigned long long int)ptr);
> >
> > I'm happy to try and work out how to do it, just chasing a 'yes that is
> > exactly the type of thing
> > cocci is good at' or a 'no, you are dreaming, perhaps can do
> > that'
>
> It's possible. Look at coccinelle/demos/format.cocci
>
> This may not be the most well tested part of Coccinelle, so if it is not
> doing what you expect, please feel free to complain.
>
> julia
Thanks Julia
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci
