Re: [MoM]: r9659 - trunk/packages/fis-gtm/fis-gtm/trunk/debian
On Wed, Feb 15, 2012 at 9:28 AM, Andreas Tille <andreas@an3as.eu> wrote:
> Hi Luis,
>
> On Wed, Feb 15, 2012 at 08:20:14AM -0500, Luis Ibanez wrote:
>> Using the ./pro/gtminstall script was almost too easy :-)
>>
>> Here is how the rules file looks like now:
>>
>>
>> override_dh_auto_install:
>> ./pro/gtminstall --utf8 default --installdir $(CURDIR)/debian/tmp
>
>
> Hmmm:
>
> debian/rules override_dh_auto_install
> make[1]: Entering directory `/tmp/buildd/fis-gtm-5.4-002B'
> ./pro/gtminstall --utf8 default --installdir /tmp/buildd/fis-gtm-5.4-002B/debian/tmp
> make[1]: ./pro/gtminstall: Command not found
> make[1]: *** [override_dh_auto_install] Error 127
> make[1]: Leaving directory `/tmp/buildd/fis-gtm-5.4-002B'
> make: *** [binary] Error 2
>
> I guess you might either have missed to copy the extra files or a
>
> cd fis-gtm-src-extras
>
> is missing.
>
Did you get this message as a result
of running "debuild" ?
I was working on the assumption that debuild goes
through a sequence of
* configure
* build
* install
and therefore, the extra files would have already
been copied in the proper locations by the time
we get to install.
Is that an incorrect assumption ?
>> I now need to look at more package examples,
>> deal with the next step of installation.
>
> What about the -I- issue which was discussed on debian-devel?
>
I started experimenting with a second patch to replace
-I- with -iquote:
$ cat 02-gtm_env_sp.patch
Author: Luis Ibanez <luis.ibanez@kitware.com>
Date: Wed Feb 15 13:03:54 UTC 2012
Description: Replace obsolete -I- compilation option with -iquote.
--- fis-gtm-5.4-002B.orig/sr_linux/gtm_env_sp.mk
+++ fis-gtm-5.4-002B/sr_linux/gtm_env_sp.mk
@@ -66,7 +66,7 @@
gt_cc_options_common+= -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
-D_XOPEN_SOURCE=600 -fsigned-char
ifeq ($(gt_build_type),32)
-gt_cc_option_I=-I-
+gt_cc_option_I=-iquote
endif
ifeq ($(gt_machine_type), x86_64)
but run into new compilation issues due to the
fact that now the order of include headers gets
to be modified.
Here is a sampler of the new errors that are
produced when introducing -iquote:
ake -C /home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/pro/obj
-I/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/pro/obj
-I/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_linux
-I/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_i386
-I/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_x86_regs
-I/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_unix_gnp
-I/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_unix_cm
-I/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_unix_nsb
-I/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_unix
-I/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_port_cm
-I/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_port
-f /home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_unix/comlist.mk
CURRENT_BUILDTYPE=pro all
Linux Host 32
Linux Host linux i386 x86_regs
Source Directory List: sr_linux sr_i386 sr_x86_regs sr_unix_gnp
sr_unix_cm sr_unix_nsb sr_unix sr_port_cm sr_port
make[3]: Entering directory
`/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/pro/obj'
In file included from
/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_port/mdef.h:86,
from
/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_port/zyerror_init.c:12:
/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_port/gtm_threadgbl.h:17:110:
error: gtm_threadgbl_deftypes.h: No such file or directory
In file included from
/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_port/mdef.h:86,
from
/home/ibanez/src/debian-med/trunk/packages/fis-gtm/fis-gtm/fis-gtm-5.4-002B/sr_port/zwr2format.c:12:
...
Here is below the conversation that I started
with Bhaskar a few minutes ago, to explore
alternative solutions:
In summary, it seems that the use of the -I- option is the
culprit of the compilation error that we see in pbuilder.
I'm attempting to replace -I- with -iquote, following
the following lines from : sr_linux/gtm_env_sp.mk
67
68 ifeq ($(gt_build_type),32)
69 gt_cc_option_I=-iquote
70 endif
71
72 ifeq ($(gt_machine_type), x86_64)
73 ifeq ($(gt_build_type),32)
74 # Do not lookup the source directory before include directories
specified by -I.
75 # gcc complains about -I- being obsolete, but using -iquote cause
build errors for gcc and as - ABS 2008.12.09
76 #
77 # The -I- option is only needed for 32 bit builds on x86_64. It
provides a feature that is not present in
78 # -iquote - namely -I- disables the ability to search the current
directory for include files. This is needed
79 # when compiling something in sr_port which includes a file that
is in both sr_port and the architecture specific
80 # sr_386. We don't want the sr_port version. An example is
sr_port/code_gen.c which includes emit_code.h.
81 # emit_code.h is found in both sr_port and sr_i386. Using -I-
will find the sr_i386 version, but without it the
82 # sr_port version is used. SLJ 2010.03.31
83
84 # The /emul/ia32-linux/... directory doesn't exist on most
machines, but when it's there we need it. No problem
85 # with always includeing it.
86
87 gt_cc_option_I+= -I/emul/ia32-linux/usr/include/
88 else
89 gt_cc_option_I=
90 endif
91 endif
92
It seems to me that we could address the problem of order of include
headers by carefully crafting the order in which they are put in the
command line. (e.g. this is how we usually handle configuration
when using CMake).
A second option, (for which have the luxury in the Debian packaging)
is that we could, during the configuration process, copy over the files
from the architecture specific directories on top of the ones in sr_port,
and in that way make the point moot. I have to admit that this is a
less elegant solution, but maybe a more expedite one...
Luis
Reply to: