caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* Problems linking in an object file produced with "ocamlopt -c -output-obj"
@ 2005-05-16 18:31 Corey O'Connor
  2005-05-17  6:14 ` Corey O'Connor
  0 siblings, 1 reply; 4+ messages in thread
From: Corey O'Connor @ 2005-05-16 18:31 UTC (permalink / raw)
  To: Ocaml

For some reason I'm trying to integrate O'Caml into XCode nicely. Add
.ml[i] files to an XCode project and they'll get compiled and linked
into a regular, native XCode target just like any other source file.

Anyways...

Since I can't make XCode use the O'Caml compiler as the linker, I am
compiling all O'Caml files into a single object that then gets passed
to the standard linker. I believe using "ocamlopt -c the_object.o
-output-obj [my compiled ocaml files...]" then passing the_object.o,
and the required O'Caml libs to the linker is the right idea.

However, the linker is still complaining about some unresolved
symbols. I've tried various combinations of libraries and link orders
but I can't figure out where these symbols are:
_caml_atom_table
_caml_static_data_end
_caml_static_data_start
_caml_code_area_end
_caml_code_area_start

Here is the relevant section of the build log:

Link command: /usr/local/bin/ocamlopt -o sources_ml.o -output-obj
unix.cmxa OpenGL.cmx Test.cmx

Ld "/Users/coconnor/Cocoa Caml Test/build/Cocoa Caml
Test.app/Contents/MacOS/Cocoa Caml Test" normal ppc
    cd "/Users/coconnor/Cocoa Caml Test"
    setenv MACOSX_DEPLOYMENT_TARGET 10.3
    /usr/bin/gcc-4.0 -o "/Users/coconnor/Cocoa Caml Test/build/Cocoa
Caml Test.app/Contents/MacOS/Cocoa Caml Test" "-L/Users/coconnor/Cocoa
Caml Test/build" -L/usr/local/lib/ocaml "-F/Users/coconnor/Cocoa Caml
Test/build" -filelist "/Users/coconnor/Cocoa Caml Test/build/Cocoa
Caml Test.build/Cocoa Caml Test.build/Objects-normal/ppc/Cocoa Caml
Test.LinkFileList" -framework Cocoa -lcamlidl -lunix -lasmrun
-framework OpenGL -lbigarray -lthreads -lnums -lstr -lcamlrun
-lthreadsnat -arch ppc
/usr/bin/ld: Undefined symbols:
_caml_atom_table
_caml_static_data_end
_caml_static_data_start
_caml_code_area_end
_caml_code_area_start


Any ideas?

-- 
-Corey O'Connor


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Problems linking in an object file produced with "ocamlopt -c -output-obj"
  2005-05-16 18:31 Problems linking in an object file produced with "ocamlopt -c -output-obj" Corey O'Connor
@ 2005-05-17  6:14 ` Corey O'Connor
  2005-05-17  6:52   ` [Caml-list] " skaller
  0 siblings, 1 reply; 4+ messages in thread
From: Corey O'Connor @ 2005-05-17  6:14 UTC (permalink / raw)
  To: Ocaml

> _caml_atom_table
> _caml_static_data_end
> _caml_static_data_start
> _caml_code_area_end
> _caml_code_area_start

Umm.. Well. I changed asmrun/startup.c from:
char * caml_static_data_start, * caml_static_data_end;
char * caml_code_area_start, * caml_code_area_end;

To:
char * caml_static_data_start, * caml_static_data_end = NULL;
char * caml_code_area_start, * caml_code_area_end = NULL;

And *poof*, the errors went away. 

This is under Mac OS X 10.4 for what it's worth. Maybe something
changed with GCC 4.0 effecting the export of extern variables with no
initializers?

-Corey O'Connor


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Caml-list] Re: Problems linking in an object file produced with "ocamlopt -c -output-obj"
  2005-05-17  6:14 ` Corey O'Connor
@ 2005-05-17  6:52   ` skaller
  2005-05-18  8:02     ` Marcin 'Qrczak' Kowalczyk
  0 siblings, 1 reply; 4+ messages in thread
From: skaller @ 2005-05-17  6:52 UTC (permalink / raw)
  To: Corey O'Connor; +Cc: Ocaml

On Tue, 2005-05-17 at 16:14, Corey O'Connor wrote:
> > _caml_atom_table
> > _caml_static_data_end
> > _caml_static_data_start
> > _caml_code_area_end
> > _caml_code_area_start
> 
> Umm.. Well. I changed asmrun/startup.c from:
> char * caml_static_data_start, * caml_static_data_end;
> char * caml_code_area_start, * caml_code_area_end;
> 
> To:
> char * caml_static_data_start, * caml_static_data_end = NULL;
> char * caml_code_area_start, * caml_code_area_end = NULL;
> 
> And *poof*, the errors went away. 
> 
> This is under Mac OS X 10.4 for what it's worth. Maybe something
> changed with GCC 4.0 effecting the export of extern variables with no
> initializers?

See ISO C99, 6.9.2./1

Variables with external linkage must be defined exactly
once (if they're used) or at most once (if they're not).

The above fragments do not constitute an external
definition, an initialiser is required for that.

The Ocaml sources are incorrect, you patch fixes them.
This should go in the bug tracker. 

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net




^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [Caml-list] Re: Problems linking in an object file produced with "ocamlopt -c -output-obj"
  2005-05-17  6:52   ` [Caml-list] " skaller
@ 2005-05-18  8:02     ` Marcin 'Qrczak' Kowalczyk
  0 siblings, 0 replies; 4+ messages in thread
From: Marcin 'Qrczak' Kowalczyk @ 2005-05-18  8:02 UTC (permalink / raw)
  To: caml-list

skaller <skaller@users.sourceforge.net> writes:

> See ISO C99, 6.9.2./1
>
> Variables with external linkage must be defined exactly
> once (if they're used) or at most once (if they're not).
>
> The above fragments do not constitute an external definition,

They do. See 6.9.2/2.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2005-05-18  8:03 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-05-16 18:31 Problems linking in an object file produced with "ocamlopt -c -output-obj" Corey O'Connor
2005-05-17  6:14 ` Corey O'Connor
2005-05-17  6:52   ` [Caml-list] " skaller
2005-05-18  8:02     ` Marcin 'Qrczak' Kowalczyk

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).