Four Js Development Tools Forum

Discussions by product => Reporting tools (GRW, GRE) => Topic started by: Brottrager H. on November 11, 2019, 12:57:16 pm



Title: libgre Bad Version
Post by: Brottrager H. on November 11, 2019, 12:57:16 pm
Hello,

We just upgraded to Version 3.20.06 of Genero Studio and are using the included Version of GRE.
However whenever we are starting a report the following error appears (err1 in Attachments).
I already tried recompiling the source files, but the same error keeps coming up.

Any ideas why this might happen?

Thanks


Title: Re: libgre Bad Version
Post by: Sebastien F. on November 11, 2019, 01:33:32 pm
Hello,

Check your GST setting and make sure that when starting fglrun, FGLLDPATH environment variable points to the correct lib directories.

https://4js.com/online_documentation/fjs-fgl-manual-html/index.html#fgl-topics/c_fgl_EnvVariables_FGLLDPATH.html

Seb


Title: Re: libgre Bad Version
Post by: Brottrager H. on November 11, 2019, 03:49:36 pm
Hello,

thank you for your time.
The FGLLDPATH variable seems to be correctly set. I added a test function to the libgre.4gl and called it in a program. While it properly linked, the error during runtime stayed.
I have also tried setting the FGLLDPATH to a new directory and copying all the *.42m modules in there and linking them one by one, but to no avail.
I lastly tried copying and renaming the source files and then proceeded as before. This produced the same error, but with a different file (LoaderStyleSheet).
My company still uses Makefiles, if that is important.

Do you know of any other issues, that can cause this error?

Thanks


Title: Re: libgre Bad Version
Post by: Reuben B. on November 11, 2019, 09:05:32 pm
If you look in $GREDIR/lib, you will see libgre.42m, LoaderStyleSheet.42m etc that are the names you are seeing in the error message.

What the error message is saying is that it these .42m have been compiled with a different version of fglcomp than what is being used by fglrun to run the program.  The difference test only applies to the first two digits of the version number e.g. , having 3.20.05 vs 3.20.06 is OK, whilst 3.10.06 vs 3.20.06 is NOT ok (the only exception to this is maybe if you participated in the EAP).

So most likely scenario is that you are running with fglrun having a 3.20 version but are still accidentally pointing at a 3.10 version of GRE.   Hence Sebs advice to check FGLLDPATH.  Directory names will vary based on your install, but does FGLLDPATH include /opt/fourjs/gre/3.10... when it should include /opt/fourjs/gre/3.20..., Another scenario is that you have correctly set FGLLDPATH=/opt/fourjs/gre/3.20... but you still have FGLDIR pointing to /opt/fourjs/fgl/3.10.  You said Makefile so double-check them and the environment.  If you were using Studio I'd say make sure the 3.10 Genero Report Writer Environment set is unchecked, and the 3.20 Genero Report Writer Environment set is checked. 

To find what version a particular .42m has been compiled with, you can run use fglrun -b

fglrun -b libgre.42m
3.20.07 /home/gst-comp/gre-src/nobackup/NIGHTLY/dist/tmp/install/src/api/libgre.4gl 2

fglrun -b libgre.42m
3.10.13 /home/gst-comp/gre-src/nobackup/NIGHTLY/dist/tmp/install/src/api/libgre.4gl 27

The first value is the FGL version that was used to compile and produce the .42m.  The second value is the name of the source directory it was compiled from, which is hopefully the directory name from our build machine.  If the directory name is something you recognise i.e the sources could have been on your machine, if you look in GREDIR/src, there is a script compile which allows you to rebuild the GREDIR libraries.  That is a third scenario which can lead to your issue, that is someone has recompiled these libraries using that compile script, and done so using the wrong fglcomp version.

Reuben








Title: Re: libgre Bad Version
Post by: Brottrager H. on November 12, 2019, 09:44:31 am
Hello,

I managed to find the issue. Somewhere during the previous installation the 42m-modules where copied into our standard working directory.
Therefore they were taking priority over any entries set in FGLLDPATH. I have overwritten them with the new modules (although I will probably delete them from the working directory later on, to not fall victim of this issue again) and the reports work properly now.

Thank you for all the infos, they helped alot in isolating the source of the issue!