Hi all:

Stephane:  I think you'll find that the run-time linking problem you've run into is the same one I ran into.  If you modify the utils.c source code to pass the -lgfs2D.la/-lgfs2D3/-lgfs3D flag a second time, your problem will be resolved.  Here's the fix I did in my code:  In the utils.c file, I added the following code around line 450, right before the MODULES_FLAGS, but after "--cflags --libs -O";  line of code, which effectively passes the appropriate flag a second time.

#if FTT_2D
    "-lgfs2D "
#elif FTT_2D3
    "-lgfs2D3 "
#else /* 3D */
    "-lgfs3D "
#endif

As for the other issues, I'm at a loss for now. 


Blake Huff
stangmechanic@gmail.com

CH-47D: 13 tons of twistin' steel and sex appeal.

On Dec 21, 2007, at 6:01 PM, Stephane Zaleski wrote:

Hi all

  depsite some repeated tests, the situation is rather confusing. I do not have the bug reported here. 
I have Mac OSX 10.4.11 and I recompiled gts/gerris today from the current darcs distribution. 

  However, one person wrote to me with a similar problem. The problem occurs 

gerris: file `vorticity.gfs' is not a valid simulation file
vorticity.gfs:5:9: error compiling expression
/usr/bin/ld: Undefined symbols:
_gfs_center_gradient
_gfs_variable_from_name
collect2: ld returned 1 exit status. 

I am trying to check with her. 

On the other hand, I do have similar problem when I try to install modules.  Of course this will be understandable only
to those who know how to create modules ... sorry. 

dhcp228:~/Documents/Cours/gerris/Exercices zaleski$ cc -global `pkg-config gerris2D --libs`  init_periodic.o -lc -o libinit_periodic2D.so
/usr/bin/ld: Undefined symbols:
_main
_ftt_cell_pos
_gfs_domain_cell_traverse
_gfs_generic_init_class
_gfs_variable_from_name
collect2: ld returned 1 exit status


I have expanded the  pkg-config output and changed the place of -lgfs2D without success: 

dhcp228:~/Documents/Cours/gerris/Exercices zaleski$ cc -global  -lgfs2D -L/usr/local/lib -L/sw/lib -L/opt/gerris/lib -lgts -lm -lgthread-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv    init_periodic.o -lc -o libinit_periodic2D.so
/usr/bin/ld: Undefined symbols:
_main
_ftt_cell_pos
_gfs_domain_cell_traverse
_gfs_generic_init_class
_gfs_variable_from_name
collect2: ld returned 1 exit status

  Best regards

Stéphane

Le 20 déc. 07 à 22:43, Stephane Popinet a écrit :

Hi Blake,

For some reason, gcc wasn't catching the -lgfs2D flag passed from
'pkg-config --cflags --libs', and the internal compile command was
failing. Adding the '-lgfs2D' (or 2D3 or 3D) flag to the Gerris
internal cccommand string after -O (or anywhere else except
immediately following the -L flags) causes linking to be properly
accomplished. I'd assume this is a bug with GCC, as the order of those
flags shouldn't matter. I just wanted to post of the problem/solution
just in case someone else has the same issue.

Thanks for tracking this down. Can other Mac Gerris users reproduce
this?

On my ubuntu system 'pkg-config --cflags --libs gerris2D' returns:

-DFTT_2D=1 -pthread -I/home/popinet/local/include
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include  -pthread
-Wl,--export-dynamic -L/home/popinet/local/lib -lgfs2D -lgts -lm
-lgthread-2.0 -lrt -lgmodule-2.0 -ldl -lglib-2.0 

Do you mean that changing that to e.g.

-DFTT_2D=1 -pthread -I/home/popinet/local/include
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include  -pthread
-Wl,--export-dynamic -lgfs2D -L/home/popinet/local/lib -lgts -lm
-lgthread-2.0 -lrt -lgmodule-2.0 -ldl -lglib-2.0 

fixes your problem?

As for the Makefile issues... While I was tracking this down, I
noticed that changes to the utils.c, boundary.c, and domain.c files
were ineffective without a clean make. Is this an issue with the
Makefile dependencies? Anyone else notice that modifications to their
code didn't stick?

Hmm never struck that on my system. Dependencies are properly
resolved... Again, did any other mac users noticed this on their
systems?

cheers

Stephane




-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
_______________________________________________
Gfs-users mailing list

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
Gfs-users mailing list
Gfs-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gfs-users