11:01 p.m.
Greetings,
I've been trying to get gretl running on my Fedora 8 Core 2 machine.
The pre-compile rpm fails with:
error: Failed dependencies:
libreadline.so.4 is needed by gretl-1.7.4-1gtk2.i586
even though readline is installed:
# rpm -qa | grep readline
readline-devel-5.2-10.fc8
readline-5.2-10.fc8
readline-5.2-10.fc8
readline-devel-5.2-10.fc8
I've created a symlink to libreadline.so.4
libreadline.so.4 -> libreadline.so.5.2
but that doesn't move the process forward.
I've tried compiling an rpm from source by taking
gretl-1.7.4/redhat/gretl.spec.in and modifying it and placing it in
/usr/src/redhat/SPECS, and the binary into /usr/src/redhat/SOURCES and
issueng the following command:
rpmbuild -bb --clean gretl.spec (when in the /usr/src/redhat/SPECS
directory)
I get the following two sets of errors:
1)
checking for LAPACK... no
*** Could not run LAPACK test program, checking why...
*** The test program failed to compile or link. See config.log for the
*** exact error that occured. This may mean LAPACK was incorrectly
installed
*** or that you have moved LAPACK since it was installed.
LAPACK is installed:
# rpm -qa | grep lapack
lapack-devel-3.1.1-2.fc8
lapack-devel-3.1.1-2.fc8
lapack-3.1.1-2.fc8
lapack-3.1.1-2.fc8
2) The rpmbuild fails with the following:
mkdir .libs
gcc -o .libs/gretlcli gretlcli.o complete.o ../lib/.libs/libgretl-1.0.so
-ldl -L/usr/local/lib -lz -lxml2 -lglib-2.0 -lgmp -lfftw3 -lm -lreadline
-ltermcap
../lib/.libs/libgretl-1.0.so: undefined reference to `dtrcon_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgels_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dspsv_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dpptri_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dpptrf_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dsycon_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dpocon_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dsyev_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgeev_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dtrtri_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgetrf_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgelss_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dorgqr_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dsytri_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dpotrf_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dsytrf_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dpotri_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgecon_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgeqrf_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dpotrs_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgesvd_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgetrs_'
../lib/.libs/libgretl-1.0.so: undefined reference to `dgetri_'
collect2: ld returned 1 exit status
make[1]: *** [gretlcli] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/gretl-1.7.4/cli'
make: *** [cli] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.19815 (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.19815 (%build)
It seems that these errors have been encountered before
(http://aur.archlinux.org/packages.php?ID=13752), but there is no solution
offered.
The contents of my gretl.spec file is appended below. Any help is
appreciated. Apologies if this has been covered elsewhere; if there are
links showing information as to how to get through this, that would be
great.
Max Pyziur
pyz(a)brama.com
######################
# cat gretl.spec
%define name gretl
%define ver 1.7.4
%define rel mp
%define prefix /usr
Summary: econometrics package
Name: %{name}
Version: %{ver}
Release: %{rel}
License: GPL
Group: Applications/Math
Source: ftp://ricardo.ecn.wfu.edu/pub/gretl/gretl-%{ver}.tar.bz2
Buildroot: %{_tmppath}/%{name}-%{ver}-%{rel}-root
Packager: Allin Cottrell <cottrell(a)wfu.edu>
URL: http://gretl.sourceforge.net/
Vendor: Allin Cottrell <cottrell(a)wfu.edu>
Docdir: %{prefix}/share/doc
Requires: gtk+ >= 1.2.3
%description
gretl is a free econometrics package. It comprises a shared library,
a command-line client and a gui client that uses GTK. gretl offers
several least-squares based estimators. Besides reading data files
in its own format it also reads RATS 4 databases. It has a built-in
spreadsheet for editing data, and uses gnuplot for graphing. It can
output regression results in LaTeX format.
%prep
%setup -q
%build
%configure
make
%install
rm -fr %{buildroot}
%makeinstall
%post
/sbin/ldconfig
%clean
rm -fr %{buildroot}
%files
%doc COPYING README INSTALL
%{prefix}/lib/lib*
%{prefix}/lib/gretl*/*
%{prefix}/bin/gretlcli
%{prefix}/bin/gretl_x11
%{prefix}/bin/gretl
%{prefix}/share/gretl/*
%{prefix}/share/locale/*
%{prefix}/share/man/*
11:14 p.m.
On Fri, 2 May 2008, Max Pyziur wrote:
I've been trying to get gretl running on my Fedora 8 Core 2
machine.
The pre-compile rpm fails with:
error: Failed dependencies:
libreadline.so.4 is needed by gretl-1.7.4-1gtk2.i586
The only RHEL system I have available to me, for building the
gretl rpm, is a fairly conservative one that uses readline 4.0.
On Fedora 8, my recommendation would be to ignore the rpm and
build from the current CVS source.
http://sourceforge.net/cvs/?group_id=36234
Allin Cottrell.
6:29 p.m.
On Fri, 2 May 2008, Allin Cottrell wrote:
On Fri, 2 May 2008, Max Pyziur wrote:
> I've been trying to get gretl running on my Fedora 8 Core 2 machine.
>
> The pre-compile rpm fails with:
> error: Failed dependencies:
> libreadline.so.4 is needed by gretl-1.7.4-1gtk2.i586
The only RHEL system I have available to me, for building the
gretl rpm, is a fairly conservative one that uses readline 4.0.
On Fedora 8, my recommendation would be to ignore the rpm and
build from the current CVS source.
http://sourceforge.net/cvs/?group_id=36234
Allin Cottrell.
Much thanks for your reply.
I have an Fedora Core 2 machine which I use as a home server. Your latest
rpm build of gretl does install on that machine. However, I still can't
build it on that machine.
I have installed gretl-1.7.4-1gtk2.i586.rpm on my Core 2 using the
--nodeps flag. As yet, I haven't tried using it, other than bringing up
the initial interface.
I have tried setting the PKG_CONFIG_PATH variable both on the FC2 as
well as the FC8 machine in the hopes of getting gretl to build. No luck.
Any further guidance would be appreciated.
Thanks!
Max Pyziur
pyz(a)brama.com
7:25 p.m.
On Sat, 3 May 2008, Max Pyziur wrote:
I have an Fedora Core 2 machine which I use as a home server.
Your latest rpm build of gretl does install on that machine.
However, I still can't build it on that machine.
I have installed gretl-1.7.4-1gtk2.i586.rpm on my Core 2 using
the --nodeps flag. As yet, I haven't tried using it, other than
bringing up the initial interface.
I have tried setting the PKG_CONFIG_PATH variable both on the
FC2 as well as the FC8 machine in the hopes of getting gretl to
build. No luck.
I'll go back to your previous message...
"I get the following two sets of errors:
1) checking for LAPACK... no
*** Could not run LAPACK test program, checking why...
*** The test program failed to compile or link. See config.log for the
*** exact error that occured. This may mean LAPACK was incorrectly installed
*** or that you have moved LAPACK since it was installed."
Well, like it says, take a look at config.log. Lapack 3.1.1 is
installed, according to rpm -qa, but maybe libblas is missing, or
maybe none of libf2c/libg2c/libgfortran can be found? liblapack is
not usable without libblas, and the lapack+blas combination in
turn is useless without a basic fortran library. On recent Fedora
I'd expect that to be libgfortran.so; on older systems it was
libg2c.so, and on even older systems, libf2c.so.
"2) The rpmbuild fails with the following:
mkdir .libs
gcc -o .libs/gretlcli gretlcli.o complete.o
../lib/.libs/libgretl-1.0.so
-ldl -L/usr/local/lib -lz -lxml2 -lglib-2.0 -lgmp -lfftw3 -lm
-lreadline -ltermcap
../lib/.libs/libgretl-1.0.so: undefined reference to `dtrcon_'"
That's just the same error: dtrcon_ is defined by liblapack.
On my system:
waverley:~$ /bin/ls -1 /usr/lib/liblapack*
/usr/lib/liblapack.so
/usr/lib/liblapack.so.3
/usr/lib/liblapack.so.3.1
/usr/lib/liblapack.so.3.1.1
waverley:~$ /bin/ls -1 /usr/lib/libblas*
/usr/lib/libblas.so
/usr/lib/libblas.so.3
/usr/lib/libblas.so.3.1
/usr/lib/libblas.so.3.1.1
waverley:~$ locate libgfortran.so
/opt/gcc4/lib/libgfortran.so
/opt/gcc4/lib/libgfortran.so.3
/opt/gcc4/lib/libgfortran.so.3.0.0
Allin Cottrell
8:43 p.m.
New subject: Progress!, was Problems building and installing on Fedora 8
On Fedora 8, libblas is installed separately. However, reviewing your
notes below I also installed blas-devel. This caused the
rpmbuild/compilation to go farther. (It might be worthwhile to this
dependency in the spec file).
The following message registered after
the configuration (which didn't before blas-devel):
Configuration:
Installation path: /usr
Use readline library: yes
Use gnuplot for graphs: yes
Use PNG for gnuplot graphs: yes
Use LaTeX for typesetting output: yes
Gnu Multiple Precision support: yes
MPFR support: yes
LAPACK support: yes
FFTW3 support: yes
Build with GTK version: 2.0
Script syntax highlighting: yes
Use installed gtksourceview: no
Use GTK printing apparatus: yes
Build with gnome support: 2.0
Build gretl documentation: no
Use Lucida fonts: no
Build message catalogs: yes
Gnome installation prefix: /usr
X-12-ARIMA support: yes
TRAMO/SEATS support: yes
Experimental audio support: no
Now type 'make' to build gretl.
+ make
...
but then it failed with the following:
gcc -o .libs/gretl_x11 about.o boxplots.o calculator.o callbacks.o
clipboard.o cmdstack.o console.o database.o datafiles.o dialogs.o
dlgutils.o filelists.o fileselect.o filters.o fncall.o fnsave.o
graph_page.o gpt_control.o gpt_dialog.o gretl.o guiprint.o gui_recode.o
gui_utils.o helpfiles.o library.o menustate.o model_table.o objectsave.o
obsbutton.o selector.o series_view.o session.o settings.o ssheet.o
textbuf.o textutil.o toolbar.o treeutils.o update.o gtkfontselhack.o
-pthread -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2
-lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lart_lgpl_2 -lgtk-x11-2.0
-lgdk-x11-2.0 -latk-1.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgconf-2
-lORBit-2 -lgthread-2.0 -lrt
-L/usr/src/redhat/BUILD/gretl-1.7.4/gui2/gtksourceview
-lgtksourceview-lite
-L/usr/src/redhat/BUILD/gretl-1.7.4/gui2/gtkextra-lite -lgtkextra-lite
../lib/.libs/libgretl-1.0.so -L/usr/lib -llapack -lblas -lgfortran
-L/usr/local/lib -lz -lxml2 -lgmp -lfftw3 -lm -lgdk_pixbuf-2.0
-lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
/usr/bin/ld: skipping incompatible /usr/lib/libgnomeui-2.so when searching
for -lgnomeui-2
/usr/bin/ld: skipping incompatible /usr/lib/libSM.so when searching for
-lSM
/usr/bin/ld: skipping incompatible /usr/lib/libbonoboui-2.so when
searching for -lbonoboui-2
/usr/bin/ld: skipping incompatible /usr/lib/libgnomevfs-2.so when
searching for -lgnomevfs-2
/usr/bin/ld: skipping incompatible /usr/lib/libgnomecanvas-2.so when
searching for -lgnomecanvas-2
/usr/bin/ld: skipping incompatible /usr/lib/libgnome-2.so when searching
for -lgnome-2
/usr/bin/ld: skipping incompatible /usr/lib/libpopt.so when searching for
-lpopt
/usr/bin/ld: skipping incompatible /usr/lib/libpopt.so when searching for
-lpopt
/usr/bin/ld: cannot find -lpopt
collect2: ld returned 1 exit status
make[1]: *** [gretl_x11] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/gretl-1.7.4/gui2'
make: *** [gui2] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.91719 (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.91719 (%build)
...
How should this be pursued?
Much thanks for all of your help.
Max Pyziur
pyz(a)brama.com
On Sat, 3 May 2008, Allin Cottrell wrote:
On Sat, 3 May 2008, Max Pyziur wrote:
> I have an Fedora Core 2 machine which I use as a home server.
> Your latest rpm build of gretl does install on that machine.
> However, I still can't build it on that machine.
>
> I have installed gretl-1.7.4-1gtk2.i586.rpm on my Core 2 using
> the --nodeps flag. As yet, I haven't tried using it, other than
> bringing up the initial interface.
>
> I have tried setting the PKG_CONFIG_PATH variable both on the
> FC2 as well as the FC8 machine in the hopes of getting gretl to
> build. No luck.
I'll go back to your previous message...
"I get the following two sets of errors:
1) checking for LAPACK... no
*** Could not run LAPACK test program, checking why...
*** The test program failed to compile or link. See config.log for the
*** exact error that occured. This may mean LAPACK was incorrectly installed
*** or that you have moved LAPACK since it was installed."
Well, like it says, take a look at config.log. Lapack 3.1.1 is
installed, according to rpm -qa, but maybe libblas is missing, or
maybe none of libf2c/libg2c/libgfortran can be found? liblapack is
not usable without libblas, and the lapack+blas combination in
turn is useless without a basic fortran library. On recent Fedora
I'd expect that to be libgfortran.so; on older systems it was
libg2c.so, and on even older systems, libf2c.so.
"2) The rpmbuild fails with the following:
mkdir .libs
gcc -o .libs/gretlcli gretlcli.o complete.o
../lib/.libs/libgretl-1.0.so
-ldl -L/usr/local/lib -lz -lxml2 -lglib-2.0 -lgmp -lfftw3 -lm
-lreadline -ltermcap
../lib/.libs/libgretl-1.0.so: undefined reference to `dtrcon_'"
That's just the same error: dtrcon_ is defined by liblapack.
On my system:
waverley:~$ /bin/ls -1 /usr/lib/liblapack*
/usr/lib/liblapack.so
/usr/lib/liblapack.so.3
/usr/lib/liblapack.so.3.1
/usr/lib/liblapack.so.3.1.1
waverley:~$ /bin/ls -1 /usr/lib/libblas*
/usr/lib/libblas.so
/usr/lib/libblas.so.3
/usr/lib/libblas.so.3.1
/usr/lib/libblas.so.3.1.1
waverley:~$ locate libgfortran.so
/opt/gcc4/lib/libgfortran.so
/opt/gcc4/lib/libgfortran.so.3
/opt/gcc4/lib/libgfortran.so.3.0.0
Allin Cottrell
_______________________________________________
Gretl-devel mailing list
Gretl-devel(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-devel
9:25 p.m.
New subject: Progress!, was Problems building and installing on Fedora 8
On Sat, 3 May 2008, Max Pyziur wrote:
On Fedora 8, libblas is installed separately. However, reviewing
your notes below I also installed blas-devel. This caused the
rpmbuild/compilation to go farther. (It might be worthwhile to
this dependency in the spec file).
The difficulty here is this: liblapack is useless without _some_
form of libblas (BLAS = Basic Linear Algebra System), but there
are various blas's. There's the libblas from the same (netlib)
source as lapack itself, and there are versions that are tuned for
best performance on a specific processor. I'd say that it's
really up to the OS/distro to ensure that if you choose to install
lapack, some suitable form of blas is pulled in as a dependency.
Or in other words, this seems like a Fedora packaging bug to me.
The following message registered after the configuration (which
didn't before blas-devel):
Configuration...
[snip]
Build with gnome support: 2.0
So far as the configure script is concerned, then, gnome is OK.
but then it failed with the following:
gcc -o .libs/gretl_x11 [object modules]
-pthread -lgnomeui-2 -lSM -lICE -lbonoboui-2
-lgnomevfs-2 -lgnomecanvas-2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation
-lart_lgpl_2 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lpangocairo-1.0
-lpango-1.0 -lcairo -lgconf-2 -lORBit-2 -lgthread-2.0 -lrt
-L/usr/src/redhat/BUILD/gretl-1.7.4/gui2/gtksourceview -lgtksourceview-lite
-L/usr/src/redhat/BUILD/gretl-1.7.4/gui2/gtkextra-lite -lgtkextra-lite
../lib/.libs/libgretl-1.0.so -L/usr/lib -llapack -lblas -lgfortran
-L/usr/local/lib -lz -lxml2 -lgmp -lfftw3 -lm -lgdk_pixbuf-2.0 -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0
/usr/bin/ld: skipping incompatible /usr/lib/libgnomeui-2.so when searching for
-lgnomeui-2
[ plus more "skipping incompatible" messages for gnome-related
libraries.]
But so far as the linker is concerned, gnome is a mess! Very
weird. What's wrong with your gnome libraries that the linker
finds them "incompatible"? Is this a 64-bit system?
You could try passing the option "--without-gnome" to configure
(or put it in the .spec file), since the linker is not barfing on
the other libraries that gretl wants. And in fact, you don't lose
much by dropping the gnome linkage.
Allin Cottrell
5:10 p.m.
New subject: Progress!, was Problems building and installing on Fedora 8
Thanks again for your help.
I'm now trying to compile/build rpms on two different Fedora 8 machines:
a 64-bit system Intel Core 2 Duo box, and
a Dell 600M Inspiron laptop w/ a Pentium M processor
I've tried your suggestion of including "--without-gnome" in the
"configure" section of the spec file on the 64-bit machine.
The rpm compilation/build proceeds further and ends with the output
appended below.
On the laptop, no "--without-gnome" directive was used. However, on the
rpm build the results were similar to those for the 64-bit machine (see
second section below).
Thanks in advance.
Max Pyziur
pyz(a)brama.com
[...]
But so far as the linker is concerned, gnome is a mess! Very
weird. What's wrong with your gnome libraries that the linker
finds them "incompatible"? Is this a 64-bit system?
You could try passing the option "--without-gnome" to configure
(or put it in the .spec file), since the linker is not barfing on
the other libraries that gretl wants. And in fact, you don't lose
much by dropping the gnome linkage.
Allin Cottrell
################ RPM build error on 64-bit machine ###################
RPM build errors:
File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/lib*
File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/gretl*/*
Installed (but unpackaged) file(s) found:
/usr/include/adf_kpss.h
/usr/include/bhhh_max.h
/usr/include/bootstrap.h
/usr/include/calendar.h
/usr/include/compare.h
/usr/include/compat.h
/usr/include/csvdata.h
/usr/include/dataio.h
/usr/include/dataset.h
/usr/include/dbread.h
/usr/include/describe.h
/usr/include/discrete.h
/usr/include/estimate.h
/usr/include/forecast.h
/usr/include/genfuncs.h
/usr/include/genmain.h
/usr/include/graphing.h
/usr/include/gretl_commands.h
/usr/include/gretl_errors.h
/usr/include/gretl_fft.h
/usr/include/gretl_func.h
/usr/include/gretl_intl.h
/usr/include/gretl_list.h
/usr/include/gretl_matrix.h
/usr/include/gretl_model.h
/usr/include/gretl_panel.h
/usr/include/gretl_paths.h
/usr/include/gretl_prn.h
/usr/include/gretl_restrict.h
/usr/include/gretl_string_table.h
/usr/include/gretl_utils.h
/usr/include/gretl_win32.h
/usr/include/gretl_www.h
/usr/include/gretl_xml.h
/usr/include/interact.h
/usr/include/johansen.h
/usr/include/kalman.h
/usr/include/libgretl.h
/usr/include/libset.h
/usr/include/matrix_extra.h
/usr/include/missing.h
/usr/include/modelprint.h
/usr/include/modelspec.h
/usr/include/monte_carlo.h
/usr/include/nls.h
/usr/include/nonparam.h
/usr/include/objstack.h
/usr/include/options.h
/usr/include/plotspec.h
/usr/include/plugins.h
/usr/include/printout.h
/usr/include/printscan.h
/usr/include/pvalues.h
/usr/include/qr_estimate.h
/usr/include/random.h
/usr/include/strutils.h
/usr/include/subsample.h
/usr/include/system.h
/usr/include/texprint.h
/usr/include/transforms.h
/usr/include/tsls.h
/usr/include/usermat.h
/usr/include/var.h
/usr/include/varprint.h
/usr/include/vartest.h
/usr/lib64/libgretl-1.0.la
/usr/lib64/libgretl-1.0.so
/usr/lib64/libgretl-1.0.so.0
/usr/lib64/libgretl-1.0.so.0.0.44
/usr/lib64/pkgconfig/gretl.pc
################## RPM Build error on 32-bit machine #################
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/include/adf_kpss.h
/usr/include/bhhh_max.h
/usr/include/bootstrap.h
/usr/include/calendar.h
/usr/include/compare.h
/usr/include/compat.h
/usr/include/csvdata.h
/usr/include/dataio.h
/usr/include/dataset.h
/usr/include/dbread.h
/usr/include/describe.h
/usr/include/discrete.h
/usr/include/estimate.h
/usr/include/forecast.h
/usr/include/genfuncs.h
/usr/include/genmain.h
/usr/include/graphing.h
/usr/include/gretl_commands.h
/usr/include/gretl_errors.h
/usr/include/gretl_fft.h
/usr/include/gretl_func.h
/usr/include/gretl_intl.h
/usr/include/gretl_list.h
/usr/include/gretl_matrix.h
/usr/include/gretl_model.h
/usr/include/gretl_panel.h
/usr/include/gretl_paths.h
/usr/include/gretl_prn.h
/usr/include/gretl_restrict.h
/usr/include/gretl_string_table.h
/usr/include/gretl_utils.h
/usr/include/gretl_win32.h
/usr/include/gretl_www.h
/usr/include/gretl_xml.h
/usr/include/interact.h
/usr/include/johansen.h
/usr/include/kalman.h
/usr/include/libgretl.h
/usr/include/libset.h
/usr/include/matrix_extra.h
/usr/include/missing.h
/usr/include/modelprint.h
/usr/include/modelspec.h
/usr/include/monte_carlo.h
/usr/include/nls.h
/usr/include/nonparam.h
/usr/include/objstack.h
/usr/include/options.h
/usr/include/plotspec.h
/usr/include/plugins.h
/usr/include/printout.h
/usr/include/printscan.h
/usr/include/pvalues.h
/usr/include/qr_estimate.h
/usr/include/random.h
/usr/include/strutils.h
/usr/include/subsample.h
/usr/include/system.h
/usr/include/texprint.h
/usr/include/transforms.h
/usr/include/tsls.h
/usr/include/usermat.h
/usr/include/var.h
/usr/include/varprint.h
/usr/include/vartest.h
/usr/lib/pkgconfig/gretl.pc
6:27 p.m.
New subject: Progress!, was Problems building and installing on Fedora 8
Trying to unravel my own thread, I appended the following lines to
gretl.spec on the 64-bit machine:
%{prefix}/share/gretl/*
%{prefix}/share/locale/*
%{prefix}/share/man/*
%{prefix}/include/*
%{prefix}/lib64/*
and have reduced errors to the following two lines on the 64-bit machine:
RPM build errors:
File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/lib*
File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/gretl*/*
On the 32-bit laptop, I appended the following lines to the gretl.spec
file:
%{prefix}/include/*
%{prefix}/lib/pkgconfig/*
and the compilation is successful. The 32-bit laptop compilation did not
use the "--without-gnome" directive in the "configure" section. The
rpm
installs successfully both on the 32-bit machine and the 64-bit machine.
On the 64-bit machine, executing:
"gretl" brings up the gretl window and has the following messages in the
terminal window
Gtk-Message: Failed to load module "gnomebreakpad": libgnomebreakpad.so:
cannot open shared object file: No such file or directory
setlocale(LC_NUMERIC, "en_US.UTF-8") returned en_US.UTF-8
"gretl_x11" produces the same results as "gretl"
"gretlcli" produces a command-line interface w/ a "?" prompt.
On the 32-bit machine, executing both "gretl" and "gretl_x11" brings
up
the gretl window and has the following message in the terminal window
setlocale(LC_NUMERIC, "en_US.UTF-8") returned en_US.UTF-8
"gretlcli" produces a command-line interface on a second try. Initially,
it produced the following:
pyz@mercury ~> gretlcli
gretl version 1.7.4
Copyright Ramu Ramanathan, Allin Cottrell and Riccardo "Jack" Lucchetti
This is free software with ABSOLUTELY NO WARRANTY
Current session: 2008/05/04 14:17
/home/pyz/.gretl/x12arima: No such file or directory
/home/pyz/.gretl/tramo: No such file or directory
No such file or directory
No such file or directory
No such file or directory
No such file or directory
Thanks! And what else is necessary to get the compilation to work on the
64-bit machine?
Max Pyziur
pyz(a)brama.com
On Sun, 4 May 2008, Max Pyziur wrote:
Thanks again for your help.
I'm now trying to compile/build rpms on two different Fedora 8 machines:
a 64-bit system Intel Core 2 Duo box, and
a Dell 600M Inspiron laptop w/ a Pentium M processor
I've tried your suggestion of including "--without-gnome" in the
"configure"
section of the spec file on the 64-bit machine.
The rpm compilation/build proceeds further and ends with the output appended
below.
On the laptop, no "--without-gnome" directive was used. However, on the rpm
build the results were similar to those for the 64-bit machine (see second
section below).
Thanks in advance.
Max Pyziur
pyz(a)brama.com
[...]
> But so far as the linker is concerned, gnome is a mess! Very
> weird. What's wrong with your gnome libraries that the linker
> finds them "incompatible"? Is this a 64-bit system?
>
> You could try passing the option "--without-gnome" to configure
> (or put it in the .spec file), since the linker is not barfing on
> the other libraries that gretl wants. And in fact, you don't lose
> much by dropping the gnome linkage.
>
> Allin Cottrell
>
################ RPM build error on 64-bit machine ###################
RPM build errors:
File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/lib*
File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/gretl*/*
Installed (but unpackaged) file(s) found:
/usr/include/adf_kpss.h
/usr/include/bhhh_max.h
/usr/include/bootstrap.h
/usr/include/calendar.h
/usr/include/compare.h
/usr/include/compat.h
/usr/include/csvdata.h
/usr/include/dataio.h
/usr/include/dataset.h
/usr/include/dbread.h
/usr/include/describe.h
/usr/include/discrete.h
/usr/include/estimate.h
/usr/include/forecast.h
/usr/include/genfuncs.h
/usr/include/genmain.h
/usr/include/graphing.h
/usr/include/gretl_commands.h
/usr/include/gretl_errors.h
/usr/include/gretl_fft.h
/usr/include/gretl_func.h
/usr/include/gretl_intl.h
/usr/include/gretl_list.h
/usr/include/gretl_matrix.h
/usr/include/gretl_model.h
/usr/include/gretl_panel.h
/usr/include/gretl_paths.h
/usr/include/gretl_prn.h
/usr/include/gretl_restrict.h
/usr/include/gretl_string_table.h
/usr/include/gretl_utils.h
/usr/include/gretl_win32.h
/usr/include/gretl_www.h
/usr/include/gretl_xml.h
/usr/include/interact.h
/usr/include/johansen.h
/usr/include/kalman.h
/usr/include/libgretl.h
/usr/include/libset.h
/usr/include/matrix_extra.h
/usr/include/missing.h
/usr/include/modelprint.h
/usr/include/modelspec.h
/usr/include/monte_carlo.h
/usr/include/nls.h
/usr/include/nonparam.h
/usr/include/objstack.h
/usr/include/options.h
/usr/include/plotspec.h
/usr/include/plugins.h
/usr/include/printout.h
/usr/include/printscan.h
/usr/include/pvalues.h
/usr/include/qr_estimate.h
/usr/include/random.h
/usr/include/strutils.h
/usr/include/subsample.h
/usr/include/system.h
/usr/include/texprint.h
/usr/include/transforms.h
/usr/include/tsls.h
/usr/include/usermat.h
/usr/include/var.h
/usr/include/varprint.h
/usr/include/vartest.h
/usr/lib64/libgretl-1.0.la
/usr/lib64/libgretl-1.0.so
/usr/lib64/libgretl-1.0.so.0
/usr/lib64/libgretl-1.0.so.0.0.44
/usr/lib64/pkgconfig/gretl.pc
################## RPM Build error on 32-bit machine #################
RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/include/adf_kpss.h
/usr/include/bhhh_max.h
/usr/include/bootstrap.h
/usr/include/calendar.h
/usr/include/compare.h
/usr/include/compat.h
/usr/include/csvdata.h
/usr/include/dataio.h
/usr/include/dataset.h
/usr/include/dbread.h
/usr/include/describe.h
/usr/include/discrete.h
/usr/include/estimate.h
/usr/include/forecast.h
/usr/include/genfuncs.h
/usr/include/genmain.h
/usr/include/graphing.h
/usr/include/gretl_commands.h
/usr/include/gretl_errors.h
/usr/include/gretl_fft.h
/usr/include/gretl_func.h
/usr/include/gretl_intl.h
/usr/include/gretl_list.h
/usr/include/gretl_matrix.h
/usr/include/gretl_model.h
/usr/include/gretl_panel.h
/usr/include/gretl_paths.h
/usr/include/gretl_prn.h
/usr/include/gretl_restrict.h
/usr/include/gretl_string_table.h
/usr/include/gretl_utils.h
/usr/include/gretl_win32.h
/usr/include/gretl_www.h
/usr/include/gretl_xml.h
/usr/include/interact.h
/usr/include/johansen.h
/usr/include/kalman.h
/usr/include/libgretl.h
/usr/include/libset.h
/usr/include/matrix_extra.h
/usr/include/missing.h
/usr/include/modelprint.h
/usr/include/modelspec.h
/usr/include/monte_carlo.h
/usr/include/nls.h
/usr/include/nonparam.h
/usr/include/objstack.h
/usr/include/options.h
/usr/include/plotspec.h
/usr/include/plugins.h
/usr/include/printout.h
/usr/include/printscan.h
/usr/include/pvalues.h
/usr/include/qr_estimate.h
/usr/include/random.h
/usr/include/strutils.h
/usr/include/subsample.h
/usr/include/system.h
/usr/include/texprint.h
/usr/include/transforms.h
/usr/include/tsls.h
/usr/include/usermat.h
/usr/include/var.h
/usr/include/varprint.h
/usr/include/vartest.h
/usr/lib/pkgconfig/gretl.pc
12:49 a.m.
New subject: Progress!, was Problems building and installing on Fedora 8
This is in reverse order, but...
On Sun, 4 May 2008, Max Pyziur wrote:
Trying to unravel my own thread, I appended the following lines
to gretl.spec on the 64-bit machine:
%{prefix}/share/gretl/*
%{prefix}/share/locale/*
%{prefix}/share/man/*
%{prefix}/include/*
That last line is wrong, isn't it? You don't want the include
directory in the spec if you're building a binary rpm.
On the 64-bit machine, executing:
"gretl" brings up the gretl window and has the following messages in the
terminal window
Gtk-Message: Failed to load module "gnomebreakpad": libgnomebreakpad.so:
cannot open shared object file: No such file or directory
I have no idea about libgnomebreakpad.so; it's not referenced
anywhere in the gretl build files. I suppose it's being dragged
in by pkg-config, in which case the pkg-config setup is broken.
Allin Cottrell.
10:26 a.m.
New subject: ARMAX and diffs
I was trying to estimate an ARIMA model with a intervention (a level shift).
I identificated a ARIMA(0,1,1) model for the data previous to the
intervention, so I tried to estimate:
Yt=w*St+[(1-\theta L)/(1-L)]*ut
St is a step variable, with value 1 after 2002:02 and 0 before that (I know
the intervention should be a gradual shift, but this is easier to explain).
The problem is that I have no very clear, based on the gretl manual, how gretl
treat the difference with the explanatory St variable. So I did some tryings
and found what I think is an inconsistency in the treatment of the explanatory
variable.
Differencing the previous equation I obtain:
d_Yt=w*Pt+(1-\theta L)*ut
where Pt=(1-L)*St.
In the following script I firstly estimate this equation with the data in the
attached file. The two following equations estimate the model in levels, but
it seems that the gretl native command does not use the St variable as
the --x12-arima, because the results are very different. I seems that gretl
is not differencing the St variable. I do that manually in the last command
and the results now seems consistent with that of X12arima and that obtained
with the first command.
<script>
open import-NE.gdt
arima 0 0 1 ; d_Y P 0
arima 0 1 1 ; Y S 0
arima 0 1 1 ; Y S 0 --x-12-arima
arima 0 1 1 ; Y P 0
</script>
Could you, Allin or Jack, please correct this behaviour?
Thanks.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.et.bs.ehu.es
1:12 p.m.
New subject: ARMAX and diffs
On Tue, 6 May 2008, Ignacio Diaz-Emparanza wrote:
I was trying to estimate an ARIMA model with a intervention (a
level shift)... and found what I think is an inconsistency in
the treatment of the explanatory variable.
Could you, Allin or Jack, please correct this behaviour?
Thanks, Ignacio. I think I'm going to wait for Jack's reaction
on this point rather than jumping in myself. But just to check my
understanding: your point is that in an ARIMA model any exogenous
variables should be subject to the same differencing that is
applied to y(t)?
Allin.
1:24 p.m.
New subject: ARMAX and diffs
On Tue, 6 May 2008, Ignacio Diaz-Emparanza wrote:
I was trying to estimate an ARIMA model with a intervention (a level
shift).
...
Could you, Allin or Jack, please correct this behaviour?
Ignacio,
after some pondering, I believe you're right. What I would consider a
proper fix for this issue, however, takes us right in the middle of the
parallel discussion about backward-incompatible changes. Let me explain.
To recap briefly what's in the manual already, what we currently have
under the "arima" heading is in fact a pair of quite different things. On
one hand, we have that ML estimation (carried out via the Kalman filter)
estimates a model like
(1) A(L) (y_t - x_t'\beta) = C(L) e_t
If we believe that the differencing operator is part and parcel of the
A(L) polynomial, we ought to difference x_t as well, not just y_t
(contrary to what we do now). This would be, in itself, a
backward-incompatible change already.
Now consider the class of models that we handle via conditional ML: here
we have
(2) A(L) y_t = x_t'\beta + C(L) e_t.
As the manual says, whenever x_t includes anything more than the constant,
(1) and (2) are fundamentally different models, since the term x_t'\beta
can be considered as the conditional mean of y_t with respect to two
different information set. In the context of (2), the A(L) polynomial does
_not_ apply to x_t, so there's no reason to difference x_t too.
The important thing here is that (1) is the formulation generally adopted
in the time-series literature, while (2) resembles more the models
econometricians use, (ARDL models, GARCH models, and so on). If we
implement the change proposed by Ignacio (which, I repeat, makes perfect
sense for (1)), the two models would diverge in their behaviour and
interpretation even more, to the point that I wouldn't find it
inconceivable to have two separate commands and two different GUI menu
entries for (1) and (2) (although, it must be said, it'd be relatively
easy to estimate (1) via conditional ML if we wanted to).
Opinions?
Riccardo (Jack) Lucchetti
Dipartimento di Economia
Università Politecnica delle Marche
r.lucchetti(a)univpm.it
http://www.econ.univpm.it/lucchetti
9:42 a.m.
New subject: ARMAX and diffs
El Tuesday 06 May 2008 15:24:16 Riccardo (Jack) Lucchetti escribió:
Ignacio,
after some pondering, I believe you're right. What I would consider a
proper fix for this issue, however, takes us right in the middle of the
parallel discussion about backward-incompatible changes. Let me explain.
To recap briefly what's in the manual already, what we currently have
under the "arima" heading is in fact a pair of quite different things. On
one hand, we have that ML estimation (carried out via the Kalman filter)
estimates a model like
(1) A(L) (y_t - x_t'\beta) = C(L) e_t
If we believe that the differencing operator is part and parcel of the
A(L) polynomial, we ought to difference x_t as well, not just y_t
(contrary to what we do now). This would be, in itself, a
backward-incompatible change already.
I think by default we should not do any "backward incomptible" changes unless
1) We are correcting an error, or
2) We are making a great improvement of some command or feature
With respect to the gretl native command "arima" I think we are not in any of
these cases, so I propose we should re-think how to solve this in another
way.
Now consider the class of models that we handle via conditional ML: here
we have
(2) A(L) y_t = x_t'\beta + C(L) e_t.
As the manual says, whenever x_t includes anything more than the constant,
(1) and (2) are fundamentally different models, since the term x_t'\beta
can be considered as the conditional mean of y_t with respect to two
different information set. In the context of (2), the A(L) polynomial does
_not_ apply to x_t, so there's no reason to difference x_t too.
The question here is the interpretation about where the unit root is. It can
go as a multiplicative factor in A(L), as it seems yo are thinking,
A(L)=A(L)'*(1-L) having A(L)' the roots outside the unit circle, or it can go
as a denominator of C(L)=C'(L)/(1-L) havin C'(L) its roots outside the unit
circle.
In equation (1) being (1-L) in A(L) or in C(L) has the same effect, but not in
equation (2).
In the context of transfer function models is very common to write the
equation as
(3) y_t = v(L)*x_t + Nt
where the noise Nt is in general Nt=C(L)/A(L)*(1-L)^d. I am working with this
type of models so I thought was natural that the xt variable I was puting in
the equation was no differenced.
The important thing here is that (1) is the formulation generally adopted
in the time-series literature, while (2) resembles more the models
econometricians use, (ARDL models, GARCH models, and so on). If we
implement the change proposed by Ignacio (which, I repeat, makes perfect
sense for (1)), the two models would diverge in their behaviour
No, please.
and
interpretation even more, to the point that I wouldn't find it
inconceivable to have two separate commands and two different GUI menu
entries for (1) and (2) (although, it must be said, it'd be relatively
easy to estimate (1) via conditional ML if we wanted to).
I think we shoud leave the things as simple as possible. Your interpretation
about the model is reasonable, so we only need that the user can know this
interpretation. If the gretl native command is left how it is now, we only
need that the user know what gretl is doing with the xt variable. So the
problem is solved if we only add a paragraph in the manual explaining how the
differences are applied to the model when there are independent variables.
But when you use the option --x12-arima the model that gretl estimates is
different that the one being estimated without this option. And I think this
is an inconsistency that should be corrected, in spite of it implies
a "backward incompatible" change.
--
Ignacio Diaz-Emparanza
DEPARTAMENTO DE ECONOMÍA APLICADA III (ECONOMETRÍA Y ESTADÍSTICA)
UPV/EHU
Avda. Lehendakari Aguirre, 83 | 48015 BILBAO
T.: +34 946013732 | F.: +34 946013754
www.et.bs.ehu.es
12:29 a.m.
New subject: Progress!, was Problems building and installing on Fedora 8
On Sun, 4 May 2008, Max Pyziur wrote:
Thanks again for your help.
I'm now trying to compile/build rpms on two different Fedora 8 machines:
a 64-bit system Intel Core 2 Duo box, and
a Dell 600M Inspiron laptop w/ a Pentium M processor
I've tried your suggestion of including "--without-gnome" in the
"configure" section of the spec file on the 64-bit machine.
The rpm compilation/build proceeds further and ends with the
output appended below.
On the laptop, no "--without-gnome" directive was used. However,
on the rpm build the results were similar to those for the
64-bit machine (see second section below).
################ RPM build error on 64-bit machine ###################
RPM build errors:
File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/lib*
File not found by glob: /var/tmp/gretl-1.7.4-mp-root/usr/lib/gretl*/*
Installed (but unpackaged) file(s) found:
/usr/include/adf_kpss.h
/usr/include/bhhh_max.h...
I'm not an rpm expert, but it appears your .spec file must be
wrong. RPM is apparently complaining about the fact that the
libgretl headers (e.g. /usr/include/adf_kpss.h) are being
installed but not packaged. That's to be expected, in a sense:
the headers are installed by a normal "make install", but one
would not expect them to be included in a binary .rpm, only in the
associated "devel" .rpm.
I suggest either (a) taking a closer look at the RPM
documentation, or (b) ignoring RPM and just installing gretl
independently of that mechanism. If you're looking to create an
RPM that you can redistribute then (a) will be required,
otherwise (b) will probably save you grief.
Allin Cottrell
6072
days inactive
6078
days old
13 comments
4 participants
participants (4)
-
Allin Cottrell -
Ignacio Diaz-Emparanza -
Max Pyziur -
Riccardo (Jack) Lucchetti