Hi,
On Sun, Jul 08, 2012 at 08:42:56PM +0200, Enrico Tassi wrote:
> On Sun, Jul 08, 2012 at 10:34:53PM +0900, Osamu Aoki wrote:
> > This is clearly regression of: lua5.1 (5.1.5-2):
> >
> > * Put in the pkg-config .pc file -DDEB_HOST_MULTIARCH so that including
> > lua.h (and consequently luaconf.h) works fine even if one is not using
> > debhelpers (Closes: #671286, LP: #977813)
> > -- Enrico Tassi <gareuselesi...@debian.org> Thu, 03 May 2012 14:34:16
> > +0200
>
> No, it's just that pkg-config changes its output w.r.t. escaping every
> day ;-)
I see.
> If you set
>
> Cflags: -I${includedir}/${lib_name_include}
> -DDEB_HOST_MULTIARCH="${deb_host_multiarch}"
>
> instead of
>
> Cflags: -I${includedir}/${lib_name_include}
> -DDEB_HOST_MULTIARCH='"${deb_host_multiarch}"'
>
> i.e. you remove ' around the value of DEB_HOST_MULTIARCH your example
> works nicely. I've added these ' just because, say, 1 month ago, a
> bugreport made them necessary.
Up to here, I am with you.
> I'm open to suggestions, but I _need_ to pass that -D option, since it
> is not just a matter of linking, it is also that the Lua rintime
> clients, including lua.h and the like, have to find where .so objects
> are, and this is DEB_HOST_MULTIARCH dependent.
Here, I am lost. I thought that *.so objects are in DEB_HOST_MULTIARCH
dependent path but that path change is taken care by the patch to the
Debian's patched loader. Also, what is lua.h. That is not arch
dependent anyway. I do not understand what are you thinking. But I am
quite new to this multi-arch thing so I guess you know better.
> > This can be fixed by debian/lua*.pc.in (just by above argument)
> >
> > -Cflags: -I${includedir}/${lib_name_include}
> > -DDEB_HOST_MULTIARCH=\"${deb_host_multiarch}\"
> > +Cflags: -I${includedir}/${lib_name_include}
> > -DDEB_HOST_MULTIARCH=${deb_host_multiarch}
> >
> > I know this may be a minimum fix for under freeze situation. But is this
> > fix the best
> > way? I do not see any other packages on my system uses this approach.
>
> IIRC the " are necessary, since in luaconf.h I have to concatenate this
> flag with other strings.
$ pwd;grep -R -i -e MULTIARCH *
/usr/include
lua5.1/luaconf.h:#define LUA_CDIR2 LUA_ROOT2 "lib/" DEB_HOST_MULTIARCH
"/lua/5.1/"
lua5.2/luaconf.h:#define LUA_CDIR2 LUA_ROOT2 "lib/" DEB_HOST_MULTIARCH
"/lua/" LUA_VDIR
Why not put the value of DEB_HOST_MULTIARCH there like libglib2.0-dev.
Of course, since file becomes arch dependent, it can not live in /usr
but need to be moved to /lib. In case of libglib2.0-dev:
$ dpkg -L libglib2.0-dev |grep '/lib/.*h$'
/usr/lib/x86_64-linux-gnu/glib-2.0/include/glibconfig.h
Then their pkg-config has:
Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include
(I guess glib has this *.h file in /lib because of 64/32 bit system difference.
I may be wrong here.)
$ grep -R "^Cflags:.*lib.*include$" *
gdkmm-3.0.pc:Cflags: -I${includedir}/gdkmm-3.0 -I${libdir}/gdkmm-3.0/include
giomm-2.4.pc:Cflags: -I${includedir}/giomm-2.4 -I${libdir}/giomm-2.4/include
glibmm-2.4.pc:Cflags: -I${includedir}/glibmm-2.4 -I${libdir}/glibmm-2.4/include
gtkmm-3.0.pc:Cflags: -I${includedir}/gtkmm-3.0 -I${libdir}/gtkmm-3.0/include
sigc++-2.0.pc:Cflags: -I${includedir}/sigc++-2.0 -I${libdir}/sigc++-2.0/include
So this removed -D while introducing -I and shuffling of file location to /lib.
Hmmm... maybe not so good ...
(-D seems to be usedonly by Qt folks in *.pc Their case is simply: -DQT_SHARED
)
> Maybe I should just use the usual CPP trick to stringify a value, and
> pass it without any kind of quotes... I'll try that, but not before
> tomorrow.
No rush ...
> Cheers
> --
> Enrico Tassi
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
