I joined the log. but it failed on gtksourceview (because i don't have this library and don't know where i can find it, fortunatly the libs module is built before it)

the problem is there are no SOURCEVIEW_LIBS into my cygwin :'( and it won't give me the way to build the .so for use modules into libgretl.

LIBS = $(GTKSOURCEVIEW_LIBS) $(GTK_LIBS) ../lib/libgretl-1.0.la

Oh ok thanks i will try. And it will solve the .so problem for loading module of libgretl ? 2010/6/14 Allin Cottrell <cottrell(a)wfu.edu&gt;: > > On Mon, 14 Jun 2010, denis joubert wrote: > >> the problem is there are no SOURCEVIEW_LIBS into my cygwin :'( >> and it won't give me the way to build the .so for use modules into libgretl. > > If an installed version of gtksourceview is not found, then the > unix-type build process uses the version that is bundled with the > gretl source (and creates a static gtksourceview library).  That > is what is happening in your case. > > My comment about reversing the link order of the libraries > still applies: if gtksourceview comes first then the linker > should find the symbols it needs in the GTK libraries. > >> LIBS = $(GTKSOURCEVIEW_LIBS) $(GTK_LIBS) ../lib/libgretl-1.0.la > > Allin Cottrell > _______________________________________________ > Gretl-users mailing list > Gretl-users(a)lists.wfu.edu > http://lists.wfu.edu/mailman/listinfo/gretl-users >

On Tue, 15 Jun 2010, denis joubert wrote: > here is the new entire make log, but without building shared > modules(like mp_ols for example) at all :'( You're making some here!

I launched the build process with the latest CVS. unfortunatly, it didn't worked with shared modules. So i sent you the log again :-)

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.

Allin Cottrell _______________________________________________ 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;: > 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: > 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.)