2:41 a.m.
Hello OS X users: I'd be grateful if any of you could try out a
new gretl dmg. This relies on the GTK+ framework that Berend
Hasselman mentioned (built by the R people), which is available
at:
http://r.research.att.com/gtk2-framework.dmg
If you don't already have this installed, you'll need to install
it first, then install
http://ricardo.ecn.wfu.edu/pub/gretl/gretltest.dmg
The advantages of this gretl build over previous ones are
1) You get a much more up-to-date version of GTK than I was able
to provide via fink on OS X 10.4, and
2) I think this should provide correct support for language
switching; at least, it does so on the iMac I'm using for testing.
If things don't work right at first, you might try deleting your
old gretl config file, ~/.gretl2rc .
--
Allin Cottrell
Department of Economics
Wake Forest University
3:48 a.m.
Allin,
I going to try out this new gretl dmg right now. As soon as I can make
the things working fine I'll report here on mailing list.
Best,
Henrique
On Sun, Apr 26, 2009 at 11:41 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
Hello OS X users: I'd be grateful if any of you could try out a
new gretl dmg. This relies on the GTK+ framework that Berend
Hasselman mentioned (built by the R people), which is available
at:
http://r.research.att.com/gtk2-framework.dmg
If you don't already have this installed, you'll need to install
it first, then install
http://ricardo.ecn.wfu.edu/pub/gretl/gretltest.dmg
The advantages of this gretl build over previous ones are
1) You get a much more up-to-date version of GTK than I was able
to provide via fink on OS X 10.4, and
2) I think this should provide correct support for language
switching; at least, it does so on the iMac I'm using for testing.
If things don't work right at first, you might try deleting your
old gretl config file, ~/.gretl2rc .
--
Allin Cottrell
Department of Economics
Wake Forest University
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
--
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
5:56 a.m.
THE NEW DMG
I'd installed the gretltest.dmg following all the instructions (delete
~/.gretl2rc, download and install GTK+, download and install gretltest.dmg).
But gretl doesn't start with double click on the icon. To use gretl I need
open a terminal and type ./gretl.
ACCENTED FILE NAMES
Accented sessions and scripts file names still don´t work.
LANGUAGES
I'd tested on my Macintosh (running OS X Leopard) and the languages that are
working fine are Automatic (that gives me gretl on my language - Brazilian
Portuguese), English, German, Spanish, French, Italian, Polish, Turkish,
Portuguese, Russian. Brazilian Portuguese and Chinese (Taiwan) didn't work.
Best,
Henrique
On Sun, Apr 26, 2009 at 11:41 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
Hello OS X users: I'd be grateful if any of you could try out a
new gretl dmg. This relies on the GTK+ framework that Berend
Hasselman mentioned (built by the R people), which is available
at:
http://r.research.att.com/gtk2-framework.dmg
If you don't already have this installed, you'll need to install
it first, then install
http://ricardo.ecn.wfu.edu/pub/gretl/gretltest.dmg
The advantages of this gretl build over previous ones are
1) You get a much more up-to-date version of GTK than I was able
to provide via fink on OS X 10.4, and
2) I think this should provide correct support for language
switching; at least, it does so on the iMac I'm using for testing.
If things don't work right at first, you might try deleting your
old gretl config file, ~/.gretl2rc .
--
Allin Cottrell
Department of Economics
Wake Forest University
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
--
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
1:40 a.m.
On Mon, 27 Apr 2009, Henrique wrote:
I'd installed the gretltest.dmg following all the instructions
(delete ~/.gretl2rc, download and install GTK+, download and
install gretltest.dmg). But gretl doesn't start with double
click on the icon. To use gretl I need open a terminal and type
./gretl.
Thanks, that should now be fixed with
http://ricardo.ecn.wfu.edu/pub/gretl/gretltest.dmg
ACCENTED FILE NAMES
Accented sessions and scripts file names still donīŋŊt work.
Non-ASCII filenames are, in my opinion, absolutely the work of
Satan. If every computer platform on the planet used UTF-8 for
encoding such filenames we might be OK but as it is, it's the
Tower of Babel all over again. And OS X seems to be a
particularly inconsistent mess (MS Windows we know will be
consistently non-standard).
For test purposes I created a file named (I'll use TeX notation
here because one can't trust email in this respect either)
"Portugu\hat{e}s.gdt" -- that is, the base name is the correct
Portuguese spelling of "Portuguese". Here's how it is represented
in various application on the iMac:
Finder: correct (I entered the name using the Finder)
xterm: Portugue\`{I}?s.gdt
native Mac Terminal program: Portugue??s.gdt
GTK file selector, as called by gretl: Portugu\hat{}es.gdt
Although the file name looks wrong in GTK (the "hat" or caret is
to the left of the 'e', not over it), the file nonetheless opens
OK.
I'd tested on my Macintosh (running OS X Leopard) and the
languages that are working fine are Automatic (that gives me
gretl on my language - Brazilian Portuguese), English, German,
Spanish, French, Italian, Polish, Turkish, Portuguese, Russian.
Brazilian Portuguese and Chinese (Taiwan) didn't work.
Thanks. I can now see how to get zh_TW to work on OS X (namely,
by setting "LANG=zh_TW LANGUAGE=zh_TW" rather than "LANG=zh_TW
LANGUAGE=chinese", as I expected), but I still don't see what the
magic incantation is to get pt_BR working.
Allin.
4:12 a.m.
Allin,
The language selection feature is now working properly (thank you!), but
everytime I try to start gretl gnuplot doesn´t work. OS X gives me the
message:
Process: gnuplot [2048]
Path: /Applications/Gretl.app/Contents/Resources/bin/gnuplot
Identifier: gnuplot
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: gretl_x11 [2009]
Date/Time: 2009-04-28 00:30:22.101 -0300
OS Version: Mac OS X 10.5.6 (9G55)
Report Version: 6
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread: 0
Dyld Error Message:
Library not loaded: /usr/local/lib/libreadline.5.2.dylib
Referenced from: /Applications/Gretl.app/Contents/Resources/bin/gnuplot
Reason: image not found
Finally, the question of accented file names remains (running gretl on
OS/X and Windows XP). Using Windows XP it's only possible open .in and
.gretl files through FILE > SCRIPT FILE or FILE > SESSION FILE (double
clicking doesn't work).
Best,
Henrique
On Mon, Apr 27, 2009 at 10:40 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Mon, 27 Apr 2009, Henrique wrote:
> I'd installed the gretltest.dmg following all the instructions
> (delete ~/.gretl2rc, download and install GTK+, download and
> install gretltest.dmg). But gretl doesn't start with double
> click on the icon. To use gretl I need open a terminal and type
> ./gretl.
Thanks, that should now be fixed with
http://ricardo.ecn.wfu.edu/pub/gretl/gretltest.dmg
> ACCENTED FILE NAMES
> Accented sessions and scripts file names still don´t work.
Non-ASCII filenames are, in my opinion, absolutely the work of
Satan. If every computer platform on the planet used UTF-8 for
encoding such filenames we might be OK but as it is, it's the
Tower of Babel all over again. And OS X seems to be a
particularly inconsistent mess (MS Windows we know will be
consistently non-standard).
For test purposes I created a file named (I'll use TeX notation
here because one can't trust email in this respect either)
"Portugu\hat{e}s.gdt" -- that is, the base name is the correct
Portuguese spelling of "Portuguese". Here's how it is represented
in various application on the iMac:
Finder: correct (I entered the name using the Finder)
xterm: Portugue\`{I}?s.gdt
native Mac Terminal program: Portugue??s.gdt
GTK file selector, as called by gretl: Portugu\hat{}es.gdt
Although the file name looks wrong in GTK (the "hat" or caret is
to the left of the 'e', not over it), the file nonetheless opens
OK.
> I'd tested on my Macintosh (running OS X Leopard) and the
> languages that are working fine are Automatic (that gives me
> gretl on my language - Brazilian Portuguese), English, German,
> Spanish, French, Italian, Polish, Turkish, Portuguese, Russian.
> Brazilian Portuguese and Chinese (Taiwan) didn't work.
Thanks. I can now see how to get zh_TW to work on OS X (namely,
by setting "LANG=zh_TW LANGUAGE=zh_TW" rather than "LANG=zh_TW
LANGUAGE=chinese", as I expected), but I still don't see what the
magic incantation is to get pt_BR working.
Allin.
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
--
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
5:22 a.m.
On Tue, 28 Apr 2009, Henrique wrote:
The language selection feature is now working properly
(thank you!), but everytime I try to start gretl gnuplot doesnīŋŊt
work. OS X gives me the message:
Process: gnuplot [2048]
Path: /Applications/Gretl.app/Contents/Resources/bin/gnuplot
Dyld Error Message:
Library not loaded: /usr/local/lib/libreadline.5.2.dylib
Reason: image not found
I've put up a new gretltest.dmg which I think should fix that
issue.
Finally, the question of accented file names remains (running
gretl on OS/X and Windows XP). Using Windows XP it's only
possible open .in and .gretl files through FILE > SCRIPT FILE or
FILE > SESSION FILE (double clicking doesn't work).
Ah, I think I know why that might be; I'll try some testing
tomorrow. Does drag-and-drop of such files onto gretl work OK?
Allin.
4:04 p.m.
New subject: win32 filenames (was Re: New build of gretl for OS X)
On Tue, 28 Apr 2009, Allin Cottrell wrote:
On Tue, 28 Apr 2009, Henrique wrote:
> Finally, the question of accented file names remains (running
> gretl on OS/X and Windows XP). Using Windows XP it's only
> possible open .in and .gretl files through FILE > SCRIPT FILE or
> FILE > SESSION FILE (double clicking doesn't work).
Ah, I think I know why that might be; I'll try some testing
tomorrow. Does drag-and-drop of such files onto gretl work OK?
I've now done some testing, and I see that neither double-clicking
nor drag-and-drop was working (or not reliably) for non-ASCII
filenames. I think this should now be fixed in the Windows
snapshot.
Allin.
6:59 p.m.
New subject: win32 filenames (was Re: New build of gretl for OS X)
Hi,
May I also ask if possible to change the default option
"show slopes at mean" as "show p-values" in Logit and
Probit. I think everybody would like to know first if an estimator is
statistically significant or not.
Best,
Bulent
Miran
> Ah, I think I know why
that might be; I'll try some testing
nor drag-and-drop was working (or not reliably) for non-ASCII
filenames. I think this should now be fixed in the Windows
snapshot.
>
> Allin.
_______________________________________________
http://lists.wfu.edu/mailman/listinfo/gretl-users
EGE ÃNÄ°VERSÄ°TESÄ°
-----------------------------------------------------------------------
Bu elektronik posta ve onunla iletilen bÃŧtÃŧn dosyalar sadece
gÃļndericisi tarafindan almasi amaclanan yetkili gercek ya da tÃŧzel
kisinin kullanimi icindir. Eger sÃļz konusu yetkili alici
degilseniz bu elektronik postanin icerigini aciklamaniz,
kopyalamaniz, yÃļnlendirmeniz ve kullanmanizkesinlikle yasaktir
ve bu elektronik postayi derhal silmeniz gerekmektedir.
EGE ÃNÄ°VERSÄ°TESÄ° bu mesajin icerdigi bilgilerin doÄruluÄu veya
eksiksiz oldugu konusunda herhangi bir garanti vermemektedir. Bu
nedenle bu bilgilerin ne sekilde olursa olsun iceriginden, iletilmesinden,
alinmasindan ve saklanmasindan sorumlu degildir.
Bu mesajdaki gÃļrÃŧsler yalnizca gÃļnderen kisiye aittir ve
EGE ÃNÄ°VERSÄ°TESÄ°'nin gÃļrÃŧslerini yansitmayabilir
-----------------------------------------------------------------------
This e-mail and any attachments may contain confidential and
privileged information. If you are not the intended recipient,
please notify the sender immediately by return e-mail, delete this
e-mail and destroy any copies. Any dissemination or use of this
information by a person other than the intended recipient is
unauthorized and may be illegal.
EGE UNIVERSITY makes no warranty as to the accuracy or completeness
of any information contained in this message and hereby excludes any
liability of any kind for the information contained therein or for
the information transmission, reception, storage or use of
such in any way whatsoever. The opinions expressed in this
message belong to sender alone and may not necessarily reflect the
opinions of EGE UNIVERSITY.
On Tue, 28 Apr 2009, Allin Cottrell wrote:
> On Tue, 28 Apr 2009, Henrique wrote:
Finally, the question of accented file names remains (running
> > gretl on OS/X and Windows XP). Using Windows XP it's
only
> > possible open .in and .gretl files through FILE
SCRIPT FILE or
> > FILE > SESSION FILE (double
clicking doesn't work).
> tomorrow. Does
drag-and-drop of such files onto gretl work
OK?
I've
now done some testing, and I see that neither double-clicking
Gretl-users
mailing list
> Gretl-users(a)lists.wfu.edu
7:29 p.m.
New subject: win32 filenames (was Re: New build of gretl for OS X)
On Tue, 28 Apr 2009, Allin Cottrell wrote:
I've now done some testing, and I see that neither double-clicking
nor drag-and-drop was working (or not reliably) for non-ASCII
filenames. I think this should now be fixed in the Windows
snapshot.
I'd just installed the win32 gretl (build date 2009-04-29) and everything is
working fine! Thank you!
But I didn't test the Mac OS version yet. As soon as I do this I'll tell you
what happened, ok?
Best,
Henrique
7:34 p.m.
New subject: win32 filenames (was Re: New build of gretl for OS X)
On Wed, 29 Apr 2009, Henrique wrote:
I'd just installed the win32 gretl (build date 2009-04-29) and
everything is
working fine! Thank you!
Good, glad to hear it!
But I didn't test the Mac OS version yet. As soon as I do this
I'll tell you
what happened, ok?
Yes indeed.
Allin.
7 p.m.
On 28-04-2009, at 07:22, Allin Cottrell wrote:
I've put up a new gretltest.dmg which I think should fix that
issue.
I have tested this on Mac OS X 10.5.6 and it worked for me.
Berend
BTW:
How did you get the @executable_path into gretcli?
Very interesting because if you can do the same with libgretl and the
gretl gui, then you probably won't have to set and use the
DYLD_LIBRARY_PATH variable any longer.
I did an otool -L on your gretlcli and got this
gretlcli:
/Users/allin/newdist/Gretl.app/Contents/Resources/lib/
libgretl-1.0.0.dylib (compatibility version 1.0.0, current version
1.50.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 88.3.11)
/usr/lib/libxml2.2.dylib (compatibility version 9.0.0,
current version 9.16.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current
version 1.2.3)
/Library/Frameworks/GTK+.framework/Versions/2.14.X11/
Resources/lib/libglib-2.0.0.dylib (compatibility version 1801.0.0,
current version 1801.1.0)
/Library/Frameworks/GTK+.framework/Versions/2.14.X11/
Resources/lib/libintl.8.dylib (compatibility version 9.0.0, current
version 9.2.0)
/usr/lib/libiconv.2.dylib (compatibility version 5.0.0,
current version 5.0.0)
@executable_path/../lib/libgmp.3.dylib (compatibility version
7.0.0, current version 7.3.0)
@executable_path/../lib/libreadline.5.2.dylib (compatibility
version 5.0.0, current version 5.2.0)
/usr/lib/libncurses.5.4.dylib (compatibility version 5.4.0,
current version 5.4.0)
7:33 p.m.
On Tue, 28 Apr 2009, Berend Hasselman wrote:
On 28-04-2009, at 07:22, Allin Cottrell wrote:
>
> I've put up a new gretltest.dmg which I think should fix that
> issue.
I have tested this on Mac OS X 10.5.6 and it worked for me.
Great, thanks.
How did you get the @executable_path into gretcli? Very
interesting because if you can do the same with libgretl and the
gretl gui, then you probably won't have to set and use the
DYLD_LIBRARY_PATH variable any longer.
Yes, you're right. I've been reading about install_name_tool,
which can be used change the install name of libraries, and to
change the links for executables. Since this seems to be working,
I'll finish the job and get rid of the DYLD_LIBRARY_PATH setting.
Thanks for suggesting the use of the R GTK+ Framework, this seems
to be a much better approach than using Fink.
Allin.
12:09 a.m.
Allin,
I still can't use Gretl (build 2009-04-28). When I double click on
Gretl's icon the system gives me:
Process: gretl_x11 [527]
Path: /Applications/Gretl.app/Contents/Resources/bin/gretl_x11
Identifier: gretl_x11
Version: ??? (???)
Code Type: X86 (Native)
Parent Process: Gretl [526]
Date/Time: 2009-04-29 20:59:33.420 -0300
OS Version: Mac OS X 10.5.6 (9G55)
Report Version: 6
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread: 0
Dyld Error Message:
Library not loaded: /usr/local/lib/libgmp.3.dylib
Referenced from:
/Applications/Gretl.app/Contents/Resources/bin/../lib/libgretl-1.0.0.dylib
Reason: image not found
Best,
Henrique
On Tue, Apr 28, 2009 at 4:33 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Tue, 28 Apr 2009, Berend Hasselman wrote:
> On 28-04-2009, at 07:22, Allin Cottrell wrote:
> >
> > I've put up a new gretltest.dmg which I think should fix that
> > issue.
>
> I have tested this on Mac OS X 10.5.6 and it worked for me.
Great, thanks.
> How did you get the @executable_path into gretcli? Very
> interesting because if you can do the same with libgretl and the
> gretl gui, then you probably won't have to set and use the
> DYLD_LIBRARY_PATH variable any longer.
Yes, you're right. I've been reading about install_name_tool,
which can be used change the install name of libraries, and to
change the links for executables. Since this seems to be working,
I'll finish the job and get rid of the DYLD_LIBRARY_PATH setting.
Thanks for suggesting the use of the R GTK+ Framework, this seems
to be a much better approach than using Fink.
Allin.
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
--
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
2:39 a.m.
On Wed, 29 Apr 2009, Henrique wrote:
I still can't use Gretl (build 2009-04-28). When I double
click on
Gretl's icon the system gives me:
Dyld Error Message:
Library not loaded: /usr/local/lib/libgmp.3.dylib
Referenced from:
/Applications/Gretl.app/Contents/Resources/bin/../lib/libgretl-1.0.0.dylib
Reason: image not found
OK, let's try one more time. I thought we could get rid of
DYLD_LIBRARY_PATH, but I guess not yet. There's a new build:
http://ricardo.ecn.wfu.edu/pub/gretl/gretltest.dmg
Allin.
2:56 a.m.
Allin, I'd just downloaded and installed the new Mac OS snapshot and it
really worked fine!
Best regards,
Henrique
On Wed, Apr 29, 2009 at 11:39 PM, Allin Cottrell <cottrell(a)wfu.edu> wrote:
On Wed, 29 Apr 2009, Henrique wrote:
> I still can't use Gretl (build 2009-04-28). When I double click on
> Gretl's icon the system gives me:
>
> Dyld Error Message:
> Library not loaded: /usr/local/lib/libgmp.3.dylib
> Referenced from:
>
/Applications/Gretl.app/Contents/Resources/bin/../lib/libgretl-1.0.0.dylib
> Reason: image not found
OK, let's try one more time. I thought we could get rid of
DYLD_LIBRARY_PATH, but I guess not yet. There's a new build:
http://ricardo.ecn.wfu.edu/pub/gretl/gretltest.dmg
Allin.
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
--
Henrique C. de Andrade
Doutorando em Economia Aplicada
Universidade Federal do Rio Grande do Sul
www.ufrgs.br/ppge
7:11 p.m.
New subject: Using the libgretl shared library in C++
Hi,
Has anyone out there ever tried to use the api-s within the shared
library from inside a C++ program? If yes, I'd like to hear about your
experience with compiling and linking your program. I have spent the
last two days trying to build an app where I want to use some basic
regression, but I cant even get past the build stage.
I get this linker error :
/app/devtools/gcc-4.3.3/bin/g++ -m64 -mtune=opteron -lpthread Main.o
-L/app/devtools/gretl-1.8.0.org/lib -lgretl-1.0
-L/app/devtools/zlib-1.2.3/lib -lz -L/app/devtools/libxml2-2.7.3/lib
-lxml2 -L/app/devtools/glib-2.14.6/lib -lglib-2.0
-L/app/devtools/refblas3-3.0-11/lib64/libblas.so.3.0.0
-L/app/devtools/liblapack3-3.2.0-5/lib64/liblapack.so.3
-L/app/devtools/fftw-3.2.1/lib -lfftw3
-L/app/devtools/gcc-4.3.3/lib64/libgfortran.so.1 -o Application.x
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgecon_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dsytri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgetrs_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dorgqr_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dpocon_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dtrcon_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgeqrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgesvd_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dtrtri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dsyev_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dsycon_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgels_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgelss_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dpptrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgemm_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgetri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dpotrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dspsv_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dsyrk_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgetrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dpotrs_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dpotri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dpptri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dsytrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgeev_'
collect2: ld returned 1 exit status
make[1]: *** [Application.x] Error 1
make[1]: Leaving directory
`/app/home/sganguly/dev/atlas-HEAD-64/atlas/src/Application'
make: *** [All] Error 2
Note that the actual gretl shared lib was built succesfully. I get these
errors in my app from which I am trying to use the gretl lib.
Any insights/pointers anyone?
PS: I have a suggestion as well - I think its best to avoid using C++
keywords such as "new" and "template" inside the C code for gretl as
this also causes trouble to folks that are trying to use the shared lib
from C++.
Thanks in advance,
Sunandan Ganguly
===============================================================================
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================
7:25 p.m.
New subject: Using the libgretl shared library in C++
Sorry, I forgot to mention my platform - Linux SLES10 64 bit AMD x86-64
Sunandan Ganguly
CREDIT SUISSE
Direct: (212) 325-0673
e-mail: sunandan.ganguly(a)credit-suisse.com
Please follow the attached hyperlink to an important disclosure:
http://www.credit-suisse.com/legal/marketcommentary
-----Original Message-----
From: gretl-users-bounces(a)lists.wfu.edu
[mailto:gretl-users-bounces@lists.wfu.edu] On Behalf Of Ganguly,
Sunandan
Sent: Thursday, April 30, 2009 3:11 PM
To: Gretl list
Subject: [Gretl-users] Using the libgretl shared library in C++
Hi,
Has anyone out there ever tried to use the api-s within the shared
library from inside a C++ program? If yes, I'd like to hear about your
experience with compiling and linking your program. I have spent the
last two days trying to build an app where I want to use some basic
regression, but I cant even get past the build stage.
I get this linker error :
/app/devtools/gcc-4.3.3/bin/g++ -m64 -mtune=opteron -lpthread Main.o
-L/app/devtools/gretl-1.8.0.org/lib -lgretl-1.0
-L/app/devtools/zlib-1.2.3/lib -lz -L/app/devtools/libxml2-2.7.3/lib
-lxml2 -L/app/devtools/glib-2.14.6/lib -lglib-2.0
-L/app/devtools/refblas3-3.0-11/lib64/libblas.so.3.0.0
-L/app/devtools/liblapack3-3.2.0-5/lib64/liblapack.so.3
-L/app/devtools/fftw-3.2.1/lib -lfftw3
-L/app/devtools/gcc-4.3.3/lib64/libgfortran.so.1 -o Application.x
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgecon_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dsytri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgetrs_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dorgqr_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dpocon_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dtrcon_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgeqrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgesvd_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dtrtri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dsyev_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dsycon_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgels_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgelss_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dpptrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgemm_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgetri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dpotrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dspsv_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dsyrk_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgetrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dpotrs_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dpotri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dpptri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dsytrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgeev_'
collect2: ld returned 1 exit status
make[1]: *** [Application.x] Error 1
make[1]: Leaving directory
`/app/home/sganguly/dev/atlas-HEAD-64/atlas/src/Application'
make: *** [All] Error 2
Note that the actual gretl shared lib was built succesfully. I get these
errors in my app from which I am trying to use the gretl lib.
Any insights/pointers anyone?
PS: I have a suggestion as well - I think its best to avoid using C++
keywords such as "new" and "template" inside the C code for gretl as
this also causes trouble to folks that are trying to use the shared lib
from C++.
Thanks in advance,
Sunandan Ganguly
========================================================================
=======
Please access the attached hyperlink for an important electronic
communications disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
========================================================================
=======
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
===============================================================================
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================
7:32 p.m.
New subject: Using the libgretl shared library in C++
I don't see any "-L" reference on your link line for the
"libgrtl-1.0.so", just the fact you want to link to it, "-l".
It appears you're building on a unix platform.. does gretl supply a precompiled binary
that runs on a unix platform, as well... and if so, can it be invoked to read a text
file.. I note that in a Windows environment it has this type of run state, as defined in
the documentation.
-----Original Message-----
From: gretl-users-bounces(a)lists.wfu.edu [mailto:gretl-users-bounces@lists.wfu.edu] On
Behalf Of Ganguly, Sunandan
Sent: Thursday, April 30, 2009 3:25 PM
To: Gretl list
Subject: RE: [Gretl-users] Using the libgretl shared library in C++
Sorry, I forgot to mention my platform - Linux SLES10 64 bit AMD x86-64
Sunandan Ganguly
CREDIT SUISSE
Direct: (212) 325-0673
e-mail: sunandan.ganguly(a)credit-suisse.com
Please follow the attached hyperlink to an important disclosure:
http://www.credit-suisse.com/legal/marketcommentary
-----Original Message-----
From: gretl-users-bounces(a)lists.wfu.edu
[mailto:gretl-users-bounces@lists.wfu.edu] On Behalf Of Ganguly, Sunandan
Sent: Thursday, April 30, 2009 3:11 PM
To: Gretl list
Subject: [Gretl-users] Using the libgretl shared library in C++
Hi,
Has anyone out there ever tried to use the api-s within the shared library from inside a
C++ program? If yes, I'd like to hear about your experience with compiling and linking
your program. I have spent the last two days trying to build an app where I want to use
some basic regression, but I cant even get past the build stage.
I get this linker error :
/app/devtools/gcc-4.3.3/bin/g++ -m64 -mtune=opteron -lpthread Main.o
-L/app/devtools/gretl-1.8.0.org/lib -lgretl-1.0 -L/app/devtools/zlib-1.2.3/lib -lz
-L/app/devtools/libxml2-2.7.3/lib
-lxml2 -L/app/devtools/glib-2.14.6/lib -lglib-2.0
-L/app/devtools/refblas3-3.0-11/lib64/libblas.so.3.0.0
-L/app/devtools/liblapack3-3.2.0-5/lib64/liblapack.so.3
-L/app/devtools/fftw-3.2.1/lib -lfftw3
-L/app/devtools/gcc-4.3.3/lib64/libgfortran.so.1 -o Application.x
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dgecon_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dsytri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dgetrs_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dorgqr_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dpocon_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dtrcon_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dgeqrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dgesvd_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dtrtri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dsyev_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dsycon_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dgels_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dgelss_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dpptrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dgemm_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dgetri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dpotrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dspsv_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dsyrk_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dgetrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dpotrs_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dpotri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dpptri_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dsytrf_'
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference to `dgeev_'
collect2: ld returned 1 exit status
make[1]: *** [Application.x] Error 1
make[1]: Leaving directory
`/app/home/sganguly/dev/atlas-HEAD-64/atlas/src/Application'
make: *** [All] Error 2
Note that the actual gretl shared lib was built succesfully. I get these errors in my app
from which I am trying to use the gretl lib.
Any insights/pointers anyone?
PS: I have a suggestion as well - I think its best to avoid using C++ keywords such as
"new" and "template" inside the C code for gretl as this also causes
trouble to folks that are trying to use the shared lib from C++.
Thanks in advance,
Sunandan Ganguly
========================================================================
=======
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
========================================================================
=======
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
===============================================================================
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
7:44 p.m.
New subject: Using the libgretl shared library in C++
On Thu, 30 Apr 2009, Ganguly, Sunandan wrote:
Has anyone out there ever tried to use the api-s within the shared
library from inside a C++ program?
No, but...
I get this linker error :
/app/devtools/gcc-4.3.3/bin/g++ -m64 -mtune=opteron -lpthread Main.o
-L/app/devtools/gretl-1.8.0.org/lib -lgretl-1.0
-L/app/devtools/zlib-1.2.3/lib -lz -L/app/devtools/libxml2-2.7.3/lib
-lxml2 -L/app/devtools/glib-2.14.6/lib -lglib-2.0
-L/app/devtools/refblas3-3.0-11/lib64/libblas.so.3.0.0
-L/app/devtools/liblapack3-3.2.0-5/lib64/liblapack.so.3
-L/app/devtools/fftw-3.2.1/lib -lfftw3
-L/app/devtools/gcc-4.3.3/lib64/libgfortran.so.1 -o Application.x
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgecon_'
What does
nm /app/devtools/liblapack3-3.2.0-5/lib64/liblapack.so.3 \
| grep dgecon
show? That symbol should be defined in liblapack. Also, what
does
ldd /app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so
show? That library should be linked against liblapack.
On my system:
waverley:~$ nm /usr/lib/liblapack.so.3 | grep dgecon
0016fca0 T dgecon_
waverley:~$ ldd /opt/esl/lib/libgretl-1.0.so
linux-gate.so.1 => (0xb7f28000)
liblapack.so => /usr/lib/liblapack.so (0xb7634000)
<etc>
PS: I have a suggestion as well - I think its best to avoid using
C++
keywords such as "new" and "template" inside the C code for gretl as
this also causes trouble to folks that are trying to use the shared lib
from C++.
Fair point; I'll make that change.
Allin Cottrell
8:18 p.m.
New subject: Using the libgretl shared library in C++
Thanks Allin.
What does nm /app/devtools/liblapack3-3.2.0-5/lib64/liblapack.so.3 \ |
grep dgecon show? That symbol should be defined in liblapack.
Hmmm. nm actually didn't recognize the file. But I did a "strings" and
was able to see the symbol.
sganguly@nyl06a-6632$ nm
/app/devtools/liblapack3-3.2.0-5/lib64/liblapack.so.3.2.0 | grep dgecon
nm: /app/devtools/liblapack3-3.2.0-5/lib64/liblapack.so.3.2.0: File
format not recognized
But,
sganguly@nyl06a-6632$ strings
/app/devtools/liblapack3-3.2.0-5/lib64/liblapack.so.3.2.0 | grep dgecon
dgecon_
dgecon
dgecon.f
dgecon
dgecon_
dgecon.f
dgecon.f
dgecon_
Maybe my liblapack.so is bad.
Also, what does
ldd /app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so
show? That library should be linked against liblapack.
That's true too. My libgretl wasn't linked against liblapack.so like
yours. But, how do I get it to?
sganguly@nyl06a-6632$ ldd
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so
libm.so.6 => /lib64/libm.so.6 (0x00002aef6c4f1000)
libdl.so.2 => /lib64/libdl.so.2 (0x00002aef6c647000)
libgmp.so.3 => /app/devtools/gmp-4.2.4/lib/libgmp.so.3
(0x00002aef6c74b000)
libc.so.6 => /lib64/libc.so.6 (0x00002aef6c889000)
/lib64/ld-linux-x86-64.so.2 (0x0000555555554000)
Sunandan Ganguly
CREDIT SUISSE
Direct: (212) 325-0673
e-mail: sunandan.ganguly(a)credit-suisse.com
Please follow the attached hyperlink to an important disclosure:
http://www.credit-suisse.com/legal/marketcommentary
-----Original Message-----
From: gretl-users-bounces(a)lists.wfu.edu
[mailto:gretl-users-bounces@lists.wfu.edu] On Behalf Of Allin Cottrell
Sent: Thursday, April 30, 2009 3:44 PM
To: Gretl list
Subject: Re: [Gretl-users] Using the libgretl shared library in C++
On Thu, 30 Apr 2009, Ganguly, Sunandan wrote:
Has anyone out there ever tried to use the api-s within the shared
library from inside a C++ program?
No, but...
I get this linker error :
/app/devtools/gcc-4.3.3/bin/g++ -m64 -mtune=opteron -lpthread Main.o
-L/app/devtools/gretl-1.8.0.org/lib -lgretl-1.0
-L/app/devtools/zlib-1.2.3/lib -lz -L/app/devtools/libxml2-2.7.3/lib
-lxml2 -L/app/devtools/glib-2.14.6/lib -lglib-2.0
-L/app/devtools/refblas3-3.0-11/lib64/libblas.so.3.0.0
-L/app/devtools/liblapack3-3.2.0-5/lib64/liblapack.so.3
-L/app/devtools/fftw-3.2.1/lib -lfftw3
-L/app/devtools/gcc-4.3.3/lib64/libgfortran.so.1 -o Application.x
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgecon_'
On my system:
waverley:~$ nm /usr/lib/liblapack.so.3 | grep dgecon 0016fca0 T dgecon_
waverley:~$ ldd /opt/esl/lib/libgretl-1.0.so
linux-gate.so.1 => (0xb7f28000)
liblapack.so => /usr/lib/liblapack.so (0xb7634000)
<etc>
PS: I have a suggestion as well - I think its best to avoid using C++
keywords such as "new" and "template" inside the C code for gretl as
this also causes trouble to folks that are trying to use the shared
lib from C++.
Fair point; I'll make that change.
Allin Cottrell
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
===============================================================================
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================
5:08 p.m.
New subject: Using the libgretl shared library in C++
Has anyone built lapack-3.2.1 on x86_64 using GCC4.3.3? I realize this
is not a lapack mailing list, but am hoping someone has done this.
I am having no joy at all:
sganguly@nyl06a-6632 lapack-3.2.1 $ make
( cd INSTALL; make; ./testlsame; ./testslamch; \
./testdlamch; ./testsecond; ./testdsecnd; ./testversion )
make[1]: Entering directory `/app/home/sganguly/lapack-3.2.1/INSTALL'
gfortran -g -o testlsame lsame.o lsametst.o
lsametst.o: In function `test1':
/home/sganguly/lapack-3.2.1/INSTALL/lsametst.f:1: undefined reference to
`_gfortran_set_options'
/app/devtools/gcc-4.3.3/lib/gcc/x86_64-unknown-linux-gnu/4.3.3/libgfortr
anbegin.a(fmain.o): In function `main':
../.././gcc-4.3.3/libgfortran/fmain.c:13: undefined reference to
`_gfortran_store_exe_path'
collect2: ld returned 1 exit status
make[1]: *** [testlsame] Error 1
make[1]: Leaving directory `/app/home/sganguly/lapack-3.2.1/INSTALL'
/bin/sh: ./testlsame: No such file or directory
/bin/sh: ./testslamch: No such file or directory
/bin/sh: ./testdlamch: No such file or directory
/bin/sh: ./testsecond: No such file or directory
/bin/sh: ./testdsecnd: No such file or directory
/bin/sh: ./testversion: No such file or directory
make: *** [lapack_install] Error 127
Thanks,
Sunandan Ganguly
Please follow the attached hyperlink to an important disclosure:
http://www.credit-suisse.com/legal/marketcommentary
-----Original Message-----
From: gretl-users-bounces(a)lists.wfu.edu
[mailto:gretl-users-bounces@lists.wfu.edu] On Behalf Of Allin Cottrell
Sent: Thursday, April 30, 2009 3:44 PM
To: Gretl list
Subject: Re: [Gretl-users] Using the libgretl shared library in C++
On Thu, 30 Apr 2009, Ganguly, Sunandan wrote:
Has anyone out there ever tried to use the api-s within the shared
library from inside a C++ program?
No, but...
I get this linker error :
/app/devtools/gcc-4.3.3/bin/g++ -m64 -mtune=opteron -lpthread Main.o
-L/app/devtools/gretl-1.8.0.org/lib -lgretl-1.0
-L/app/devtools/zlib-1.2.3/lib -lz -L/app/devtools/libxml2-2.7.3/lib
-lxml2 -L/app/devtools/glib-2.14.6/lib -lglib-2.0
-L/app/devtools/refblas3-3.0-11/lib64/libblas.so.3.0.0
-L/app/devtools/liblapack3-3.2.0-5/lib64/liblapack.so.3
-L/app/devtools/fftw-3.2.1/lib -lfftw3
-L/app/devtools/gcc-4.3.3/lib64/libgfortran.so.1 -o Application.x
/app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so: undefined reference
to `dgecon_'
What does
nm /app/devtools/liblapack3-3.2.0-5/lib64/liblapack.so.3 \ | grep
dgecon
show? That symbol should be defined in liblapack. Also, what does
ldd /app/devtools/gretl-1.8.0.org/lib/libgretl-1.0.so
show? That library should be linked against liblapack.
On my system:
waverley:~$ nm /usr/lib/liblapack.so.3 | grep dgecon 0016fca0 T dgecon_
waverley:~$ ldd /opt/esl/lib/libgretl-1.0.so
linux-gate.so.1 => (0xb7f28000)
liblapack.so => /usr/lib/liblapack.so (0xb7634000)
<etc>
PS: I have a suggestion as well - I think its best to avoid using C++
keywords such as "new" and "template" inside the C code for gretl as
this also causes trouble to folks that are trying to use the shared
lib from C++.
Fair point; I'll make that change.
Allin Cottrell
_______________________________________________
Gretl-users mailing list
Gretl-users(a)lists.wfu.edu
http://lists.wfu.edu/mailman/listinfo/gretl-users
===============================================================================
Please access the attached hyperlink for an important electronic communications
disclaimer:
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html
===============================================================================
3:39 p.m.
New subject: Using the libgretl shared library in C++
On Wed, 6 May 2009, Ganguly, Sunandan wrote:
Has anyone built lapack-3.2.1 on x86_64 using GCC4.3.3? I realize
this
is not a lapack mailing list, but am hoping someone has done this.
I am having no joy at all:
sganguly@nyl06a-6632 lapack-3.2.1 $ make
( cd INSTALL; make; ./testlsame; ./testslamch; \
./testdlamch; ./testsecond; ./testdsecnd; ./testversion )
make[1]: Entering directory `/app/home/sganguly/lapack-3.2.1/INSTALL'
gfortran -g -o testlsame lsame.o lsametst.o
lsametst.o: In function `test1':
/home/sganguly/lapack-3.2.1/INSTALL/lsametst.f:1: undefined reference to
`_gfortran_set_options'
I haven't done any building of 64-bit code, but on my system
_gfortran_set_options is defined in libgfortran.so.3.0.0 and also
in the static library libgfortran.a.
Allin Cottrell
6:11 a.m.
On 30-04-2009, at 04:39, Allin Cottrell wrote:
On Wed, 29 Apr 2009, Henrique wrote:
> I still can't use Gretl (build 2009-04-28). When I double click on
> Gretl's icon the system gives me:
>
> Dyld Error Message:
> Library not loaded: /usr/local/lib/libgmp.3.dylib
> Referenced from:
> /Applications/Gretl.app/Contents/Resources/bin/../lib/
> libgretl-1.0.0.dylib
> Reason: image not found
OK, let's try one more time. I thought we could get rid of
DYLD_LIBRARY_PATH, but I guess not yet. There's a new build:
You can get rid of it. This page was helpful for me:
www.cocoadev.com/index.pl?ApplicationLinking
But all references to dynamic libraries (not only those in an
executable) have to be modified with the @executable_path thing.
So if libgretl uses libgmp then that reference too must be changed to
use @executable_path.
Also references in all .so files will have to be changed.
It took some experimenting to get it all working but I think the
script at the end of this message will do the job of modifying all
references to "private" dylib's into references with @executable_path.
The script must be run in the directory where the Gretl.app resides.
Change the environment variables SRCPATH as appropriate.
Berend
Script starts here:
TOOL=install_name_tool
GRETLRES=Gretl.app/Contents/Resources
SRCPATH=/Users/berendhasselman/tmp/gretl-i386/lib
# path to dylib relative to path of executable
# executable here is the thing in directory bin
# I hope!
DSTPATH=@executable_path/../lib
# change install name of libraries
$TOOL -id ${DSTPATH}/libgretl-1.0.0.dylib ${GRETLRES}/lib/
libgretl-1.0.0.dylib
$TOOL -id ${DSTPATH}/libgmp.3.4.4.dylib ${GRETLRES}/lib/libgmp.
3.dylib
$TOOL -id ${DSTPATH}/libmpfr.1.1.2.dylib ${GRETLRES}/lib/libmpfr.
1.dylib
# change copied install names
$TOOL -change ${SRCPATH}/libgretl-1.0.0.dylib ${DSTPATH}/
libgretl-1.0.0.dylib \
${GRETLRES}/bin/gretl_x11
$TOOL -change ${SRCPATH}/libgmp.3.dylib ${DSTPATH}/libgmp.3.dylib \
${GRETLRES}/bin/gretl_x11
$TOOL -change ${SRCPATH}/libgretl-1.0.0.dylib ${DSTPATH}/
libgretl-1.0.0.dylib \
${GRETLRES}/bin/gretlcli
$TOOL -change ${SRCPATH}/libgmp.3.dylib ${DSTPATH}/libgmp.3.dylib \
${GRETLRES}/bin/gretlcli
$TOOL -change ${SRCPATH}/libgmp.3.dylib ${DSTPATH}/libgmp.3.dylib \
${GRETLRES}/lib/libgretl-1.0.0.dylib
$TOOL -change ${SRCPATH}/libgmp.3.dylib ${DSTPATH}/libgmp.3.dylib \
${GRETLRES}/lib/libmpfr.1.1.2.dylib
for d in ${GRETLRES}/lib/gretl-gtk2/*.so
do
$TOOL -change ${SRCPATH}/libgmp.3.dylib ${DSTPATH}/libgmp.
3.dylib $d
$TOOL -change ${SRCPATH}/libgretl-1.0.0.dylib ${DSTPATH}/
libgretl-1.0.0.dylib $d
done
d=${GRETLRES}/lib/gretl-gtk2/mp_ols.so
$TOOL -change ${SRCPATH}/libmpfr.1.dylib ${DSTPATH}/libmpfr.1.dylib $d
12:06 a.m.
On Thu, 30 Apr 2009, Berend Hasselman wrote:
On 30-04-2009, at 04:39, Allin Cottrell wrote:
> OK, let's try one more time. I thought we could get rid of
> DYLD_LIBRARY_PATH, but I guess not yet. There's a new build:
You can get rid of it. This page was helpful for me:
www.cocoadev.com/index.pl?ApplicationLinking
Thanks. Yes, I know that in principle we can get rid of
DYLD_LIBRARY_PATH, it's just a matter of getting all the details
right so that things actually work for all users without that
work-around.
The script you gave was certainly helpful, thank you. But (just
to indicate the issues involved) it didn't cover use of
libreadline in gretlcli, or the possibility that the default
linkage of some of the libraries in question is to some
third-party location (e.g. /usr/local/lib or /sw/lib).
Before I truly and finally get rid of DYLD_LIBRARY_PATH I have to
make sure that all such possibilities are covered.
Allin Cottrell
7:47 a.m.
On 01-05-2009, at 02:06, Allin Cottrell wrote:
The script you gave was certainly helpful, thank you. But (just
to indicate the issues involved) it didn't cover use of
libreadline in gretlcli, or the possibility that the default
linkage of some of the libraries in question is to some
third-party location (e.g. /usr/local/lib or /sw/lib).
The script was made with information provided by otool -L on the gretl
I have compiled without fink and with R GTK.
I am linking to the MC OS X editline.dylib which works (I have had all
sorts of weird issues compiling and/or linking to readline caused by
Mac OS X using editline and not GNU readline).
Before I truly and finally get rid of DYLD_LIBRARY_PATH I have to
make sure that all such possibilities are covered.
Indeed. I traced all references manually with the aid of otool.
In trying to get rid of DYLD_LIBRARY_PATH, I encountered something
else which I don't understand.
I have the gfortran compiler from the R MAC OS X project installed.
It installs all its library stuff in /usr/local/lib including a
libgcc_s-1.dylib
The configure process of Gretl seems to include /usr/local/lib at the
head of a library search list.
This led to all libraries and executables using /usr/local/lib/
libgcc_s-1.dylib instead of simply the standard C /usr/lib/
libgcc_s-1.dylib.
I had to use install_name_tool to change the references to the
standard C dylib (dangerous but it works).
It appears that /usr/local/lib is already on the linker search list so
it wouldn't have to be included explicitly.
I haven't got a clue how to avoid that inclusion and would like some
enlightenment.
Berend
6:16 p.m.
On Fri, 1 May 2009, Berend Hasselman wrote:
In trying to get rid of DYLD_LIBRARY_PATH, I encountered something
else which I don't understand.
I have the gfortran compiler from the R MAC OS X project installed.
It installs all its library stuff in /usr/local/lib including a
libgcc_s-1.dylib
The configure process of Gretl seems to include /usr/local/lib at the
head of a library search list.
This led to all libraries and executables using /usr/local/lib/
libgcc_s-1.dylib instead of simply the standard C /usr/lib/
libgcc_s-1.dylib...
Ah, lib/Makefile.in had a hard coded "-L/usr/local/lib" that
really shouldn't be there. I've now removed it.
Allin.
8:25 p.m.
On Fri, 1 May 2009, Berend Hasselman wrote:
The script was made with information provided by otool -L on the
gretl I have compiled without fink and with R GTK...
I have added a new target to the top-level gretl Makefile,
"osx-dist". This calls "make -C osx postinst" which does three
things:
1. Deletes some extraneous files that we assume will not be wanted
in the disk image (such as headers and libtool .la files).
2. Replaces the regular "gretl" script with an OS X-special
version.
3. Runs osx/fixlinks.sh, which is a script to fix the install
names of executables and libraries. This is based on your script.
There's one remaining issue with osx/fixlinks.sh -- the path that
will be present in "auxiliary" libs such as libgmp and libmpfr.
This is given by the variable
AUXPATH="/usr/local/lib"
and this will have to be changed manually if it's not right.
I've also added a configure option, "--disable-gnuplot-checks".
You can use this if you're confident that gnuplot is in fact OK
but there might be some problem with determining this at build
time.
For the dmg, I'm now building CVS gnuplot 4.3 using the GTK+
framework to enable the pngcairo and pdfcairo terminals (and thus
cutting out dependencies on libgd and libpdf). I've put an
archive of the source I'm using at
http://ricardo.ecn.wfu.edu/pub/gretl/osxbuild/gnuplot-20090503.tar.gz
Allin.
8:45 p.m.
On Sun, 3 May 2009, Allin Cottrell wrote:
There's one remaining issue with osx/fixlinks.sh -- the path
that
will be present in "auxiliary" libs such as libgmp and libmpfr.
This is given by the variable
AUXPATH="/usr/local/lib"
and this will have to be changed manually if it's not right.
That's now slightly improved: the script will respect a setting
for AUXPATH via an envionment variable (but will fall back on
/usr/local/lib if there's no setting). So:
AUXPATH=/some/place make osx-dist
(The trouble with edting fixlinks.sh is that it's a generated file
that will be over-written every time the configure script is run.)
Allin.
3:05 p.m.
On 27-04-2009, at 04:41, Allin Cottrell wrote:
Hello OS X users: I'd be grateful if any of you could try out a
new gretl dmg. This relies on the GTK+ framework that Berend
Hasselman mentioned (built by the R people), which is available
at:
http://r.research.att.com/gtk2-framework.dmg
If you don't already have this installed, you'll need to install
it first, then install
http://ricardo.ecn.wfu.edu/pub/gretl/gretltest.dmg
The advantages of this gretl build over previous ones are
Gretl.app is not recognized by Mac OS X.
The Finder gives the message: You can't open the application
"Gretl.app" because it is not supported on this architecture.
Looking into the package it seems that Gretl.app does not contain the
correct structure of directories and ScriptExec to start the
application.
As an aside:
When this becomes final, it may a good idea to redirect the stderr
handle to /dev/null like so
exec "$CWD/gretl_x11" "$@" 2> /dev/null
to avoid the console.log being flooded with messages.
It appears that Pango gives a lot of seemingly harmless error
messages. I went looking on the web and it seems that this is an error
in Pango and can be ignored. Also GTK outputs some warnings.
Berend
4:01 p.m.
On Mon, 27 Apr 2009, Berend Hasselman wrote:
Gretl.app is not recognized by Mac OS X.
The Finder gives the message: You can't open the application
"Gretl.app" because it is not supported on this architecture.
Thanks for the report; clearly I omitted to copy across all the
files need for the ScriptExec thing. I'll make a revised dmg this
evening.
Allin Cottrell
5713
days inactive
5723
days old
30 comments
6 participants
participants (6)
-
Allin Cottrell -
Berend Hasselman -
bulent.miranīŧ ege.edu.tr -
Ganguly, Sunandan -
Helden, Stephen -
Henrique