Hello, I found something some things to try. But it will work only for cygwin (it's not recommended for all systems so conditional usage should be done) 1) Adding this in the libtool command line can solve the problem : -no-undefined 2) Adding in configure.in (ou configure.ac), before macro AC_PROG_LIBTOOL the line below : lt_cv_deplibs_check_method='pass_all' I cannot try it before around 8 hours. I have no access to cvs repository where i am now (cvs port are not allowed). 2010/6/17 denis joubert <denis.joubert(a)gmail.com&gt;: > Ok sorry. switching to gretl-dev for this. > history of the discussion added. > I have no more informations this morning i will looking for libtool issues. > > 2010/6/17 Riccardo (Jack) Lucchetti <r.lucchetti(a)univpm.it&gt;: >> On Wed, 16 Jun 2010, Allin Cottrell wrote: >> >>> >>> On Thu, 17 Jun 2010, denis joubert wrote: >>> >>>> Oups an error was done in the previous message... >>> >>> Thanks, Denis, but I think this quite specialized discussion may >>> be trying the patience of subscribers to the gretl-users list. I >>> don't want to cut you off -- it would be very good to come up with >>> a workable recipe for building gretl on cygwin -- but I'd suggest >>> either using the gretl-devel mailing list (google: gretl-devel) or >>> switching to personal email with me. (I'm interested and would >>> like to continue discussion.) >> >> Please keep this thread in gretl-devel. I'm interested too. >> >> >> Riccardo (Jack) Lucchetti >> Dipartimento di Economia >> Università Politecnica delle Marche >> >> r.lucchetti(a)univpm.it >> http://www.econ.univpm.it/lucchetti >> _______________________________________________ >> Gretl-users mailing list >> Gretl-users(a)lists.wfu.edu >> http://lists.wfu.edu/mailman/listinfo/gretl-users >> > > Hello Allin, > I found some clues of what is going on when linking the shared librairies . > I added a -debug into the libtool command line and get back what it is > doing (log joined). > So i got the libraries he used to try its link : > + deplibs='/usr/lib/libgmp.dll.a /usr/lib/libiconv.dll.a > /usr/lib/libintl.dll.a /usr/lib/libpcre.dll.a > /usr/lib/libglib-2.0.dll.a -lz /usr/lib/libxml2.dll.a -ldl -lgfortran > /usr/lib/libblas.dll.a /usr/lib/liblapack.dll.a -L/usr/lib -L/usr/lib > ' > > When i link manualy a module it work only if add libgretl-1.0.a or > libgretl-1.0.so, you can try for example : > $ g++ ./.libs/arbond.o /usr/lib/libgmp.dll.a /usr/lib/libiconv.dll.a > /usr/lib/libintl.dll.a /usr/lib/libpcre.dll.a > /usr/lib/libglib-2.0.dll.a -lz /usr/lib/libxml2.dll.a -ldl -lgfortran > /usr/lib/libblas.dll.a /usr/lib/liblapack.dll.a -L/usr/lib > ../lib/libgretl-1.0.so -L/usr/lib -shared -o test.so > > And libtool say what the problem is to us : > *** Warning: This system can not link to static lib archive > ../lib/libgretl-1.0.la. > *** I have the capability to make that library automatically link in when > *** you link to this library.  But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > *** But as you try to build a module library, libtool will still create > *** a static module, that should work as long as the dlopening application > *** is linked with the -dlopen flag to resolve symbols at runtime. > > So he said that the module should be linked with libgretl-1.0 in > shared version !!! But there are the same problem with libgretl-1.0 > (undefined symbol) > so i build myself with my hands libgretl-1.0.dll (with the same > arguments sent to libtool): > g++ adf_kpss.o bhhh_max.o bootstrap.o boxplots.o calendar.o compare.o > compat.o csvdata.o dataio.o dataset.o dbread.o dbwrite.o describe.o > discrete.o estimate.o flow_control.o forecast.o geneval.o genfuncs.o > genlex.o genmain.o gensyntax.o gmm.o graphing.o gretl_bfgs.o > gretl_bundle.o gretl_commands.o gretl_errors.o gretl_fft.o > gretl_foreign.o gretl_func.o gretl_intl.o gretl_list.o gretl_matrix.o > gretl_model.o gretl_panel.o gretl_paths.o gretl_prn.o gretl_restrict.o > gretl_scalar.o gretl_string_table.o gretl_untar.o gretl_utils.o > gretl_www.o gretl_xml.o interact.o kalman.o libset.o matrix_extra.o > missing.o modelprint.o monte_carlo.o nls.o nonparam.o objstack.o > options.o plotspec.o plugins.o printout.o printscan.o pvalues.o > qr_estimate.o random.o strutils.o subsample.o system.o texprint.o > transforms.o tsls.o usermat.o var.o varprint.o vartest.o irfboot.o > bdtr.o btdtr.o chbevl.o chdtr.o const.o expx2.o fdtr.o gamma.o gdtr.o > igam.o igami.o incbet.o incbi.o mtherr.o nbdtr.o ndtr.o ndtri.o pdtr.o > polevl.o polrt.o stdtr.o unity.o airy.o hyp2f1.o hyperg.o i0.o i1.o > iv.o j0.o j1.o jn.o jv.o k0.o k1.o kn.o psi.o struve.o yn.o kv.o > chkder.o dpmpar.o enorm.o fdjac2.o lmder.o lmder1.o lmdif.o lmpar.o > qrfac.o qrsolv.o dlog10.o lbfgsb.o -L/usr/lib -llapack -lblas > -lgfortran -lm -ldl -lz -lxml2 -lz -liconv -lm  -lglib-2.0 -lintl > -liconv -lgmp -lfftw3 -lm  -shared -o libgretl-1.0.dll > > Strange it works... > > so back to the plugins : > what the hell !!! I got only : > ../libtool --mode=link gcc -module -avoid-version -rpath /usr/lib/gretl-gtk2 -o > arbond.la arbond.lo ../lib/libgretl-1.0.la > libtool: link: warning: undefined symbols not allowed in > i686-pc-cygwin shared libraries > > ARGH ! > > There is something tricky with the cygwin version of libtool even with > a right order of libraries he always find there are undefined > symbols... > > thanks. > > 2010/6/16 denis joubert <denis.joubert(a)gmail.com&gt;: > - Masquer le texte des messages précédents - >> 2010/6/16 Allin Cottrell <cottrell(a)wfu.edu&gt;: >>> >>> On Wed, 16 Jun 2010, denis joubert wrote: >>> >>>> I launched the build process with the latest CVS. >>>> unfortunatly, it didn't worked with shared modules. >>>> So i sent you the log again :-) >>> >>> Thanks! We're still hung up on cygwin's inability to create a >>> shared libgretl (that is what is subsequently making it impossible >>> to build the gretl plugins as shared modules). >>> >>> This time, however, the compiler is giving no clue as what >>> undefined symbols are bothering it when trying to link libgretl. >>> (Before, there was a reference to "errno" being a problem, but >>> that is now gone with current CVS, as should be.) >>> >>> This is quite puzzling, since it seems that all the symbols needed >>> by libgretl should be provided by the various shared libraries on >>> the linker line (libm, libz, libxml2, etc.). Indeed, this >>> condition is satisfied when building on OS X, where the compiler >>> also refuses to build a shared library if there are undefined >>> symbols. >>> >>> Somehow we need to get the compiler to tell us what it thinks is >>> missing. I'll see what I can find out about that. >> >> I have some experiences with that I will try to find out about it too >> if I could get some time for. >> >>> >>> Allin Cottrell >>> _______________________________________________ >>> Gretl-users mailing list >>> Gretl-users(a)lists.wfu.edu >>> http://lists.wfu.edu/mailman/listinfo/gretl-users >>> >> >

On Thu, 17 Jun 2010, denis joubert wrote: > Solution found to make a libgretl-1.0.dll.a & libgretl-1.0.dll: > 1) -no-undefined should be added to libtool command line when > compiling under cygwin otherwise no shared libraries can be built > 2) the library -lgfortran doesnt exist in cygwin (it's only a compiler > options of gcc) so you need to replace it with -XCClinker,-lgfortran > because libtool cannot find a library and doesn't want to build the > dll Bingo! Excellent. I've modified ltmain.sh and configure.in in the gretl source accordingly. Allin _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

Sorry the correction wasn't totally good. you should do a specific conditional part for cygwin in plugin.c because of this line : append_dir(pluginpath, "plugins"); 2010/6/17 denis joubert <denis.joubert(a)gmail.com&gt;: > Thanks Allin :-) > I got another problem...unfortunatly when you are on cygwin it's .dll > extension for the plugin. and when i compiled a program with libgretl > he ask me .so library at the runtime. > > But in plugin.c, there is a WIN32 macro which defines if you use .dll or .so > So another macro (CYGWIN) should be defined in the config.h by the > configure when it detects cygwin environnement and plugin.c should be > updated with the next line : > #if defined(WIN32) || defined(CYGWIN) >    append_dir(pluginpath, "plugins"); >    strcat(pluginpath, plugin); >    strcat(pluginpath, ".dll"); > > > 2010/6/17 Allin Cottrell <cottrell(a)wfu.edu&gt;: >> >> On Thu, 17 Jun 2010, denis joubert wrote: >> >>> Solution found to make a libgretl-1.0.dll.a & libgretl-1.0.dll: >>> 1) -no-undefined should be added to libtool command line when >>> compiling under cygwin otherwise no shared libraries can be built >>> 2) the library -lgfortran doesnt exist in cygwin (it's only a compiler >>> options of gcc) so you need to replace it with -XCClinker,-lgfortran >>> because libtool cannot find a library and doesn't want to build the >>> dll >> >> Bingo! Excellent. I've modified ltmain.sh and configure.in in the >> gretl source accordingly. >> >> Allin >> _______________________________________________ >> Gretl-devel mailing list >> Gretl-devel(a)lists.wfu.edu >> http://lists.wfu.edu/mailman/listinfo/gretl-devel >> >

On Thu, 17 Jun 2010, denis joubert wrote: > and you need to set the environnement with the path of the plugins like this : > export LD_LIBRARY_PATH=/usr/lib/gretl-gtk2 > (i installed gretl in /usr) Why is that needed? The gretl plugins are dlopen'd on demand. Provided the path to the plugins is right (and I think we just fixed that, with the change to plugins.c) I don't see any reason why the plugins directory needs to be in LD_LIBRARY_PATH. That's certainly not the case on Linux or OS X. Allin _______________________________________________ Gretl-devel mailing list Gretl-devel(a)lists.wfu.edu http://lists.wfu.edu/mailman/listinfo/gretl-devel

Thanks Allin :-) I got another problem...unfortunatly when you are on cygwin it's .dll extension for the plugin. and when i compiled a program with libgretl he ask me .so library at the runtime.