Le lundi 04 juillet 2005 à 09:03 +0300, Tommi Hassinen a écrit : > On Sun, 3 Jul 2005, Jean Bréfort wrote: > > > Hi, > > > > I found other build issues: > > > > In file included from ./filetrans.h:16, > > from ./filetrans.cpp:10: > > ./appconfig.h:63:1: warning: "PACKAGE_NAME" redefined > > In file included from ./filetrans.h:13, > > from ./filetrans.cpp:10: > > /usr/local/include/ghemical/libconfig.h:71:1: warning: this is the > > location of the previous definition > > > > I think that including a *config.h file in headers is generally a very > > bad idea and should be done only if absolutely necessary. If necessary > > (seems it is the case for some files), it is possible to use a solution > > like the one used in openbabel: > > > > AM_CONFIG_HEADER(src/config.h) > > ... > > AC_CONFIG_COMMANDS([src/libconfig.h], > > [cat src/config.h | grep -v PACKAGE >src/libconfig.h]) > > > > and add #include <config.h> in cpp files when the PACKAGE* variables are > > needed (i.e. nowhere in libghemical). > > I have used the following "config"-headers: > > libconfig.h in libghemical > appconfig.h in ghemical > > I used names other than simply "config.h" so that the header file would > not so easily mix if other packages also have a file config.h. I understane, but the problem is that bowt hdefiune PACKAGE_NAME and two others with different values. re-naming them will not solve the problem. The AC_CONGIF_COMMAND above just removes the PACKAGE* variables from the public config file. > But if needed I can re-name them again to be even more unique. > > I have mostly used the config.h style headers just to reduce the amount of > all flags and junk that go into the g++ command line. Also when you are > debugging or looking how things work, you can see what the settings were > in a file but often it's hard to find out those macro settings that were > just at the command line. > > > When compiling ghemical on an amd64, I get lot of messages like this > > one: > > ./project.cpp:2804: warning: cast from pointer to integer of different > > size. > > Is the above line at cvs HEAD version (1.90)? If yes it looks like this: > > glPushName(GLNAME_MD_TYPE1); glPushName((i32u) & (* it1)); > > The problem here seems to relate to OpenGL graphics API, where for > selecting objects later some "names" must be given to objects. The "name" > is a 32-bit number, so I have just used the memory address (pointer) of > the object as it's name. > > So far it has worked, but in a 64-bit OS this clearly needs to be changed. > I just need to re-think this object naming system, to adapt it so that it > works also with 64 bit pointers. > > > This MUST be fixed. It is quite unsafe. If you try to convert the 32 > > bits int back to a pointer, you will probably have crashes (it will > > occur if the object is on the stack). > > Yep. > > > I also think you should use openbabel-2 for gchemical-2. I can help with > > that if needed. > > Thanks. I think I need a few days to try it first, let's then get back > into this matter. I did that already for gchempaint (cvs version). See the more recent commits. Btw, I could compile ghemical-1.90 on my laptop. It seems I cannot export molecules from gchempaint to ghemical-1.90. It does not read the gpr files written using openbabel? Best regards, Jean