Re: [Godi-list] Small problem using godi

2009-12-28 Thread Gerd Stolpmann

Am Samstag, den 26.12.2009, 15:47 +0100 schrieb Anders Thøgersen:
 Hi,
 
 On 22:05 Sun 20 Dec 2009, Gerd Stolpmann wrote:
  
  Am Mittwoch, den 16.12.2009, 01:50 +0100 schrieb Anders Thøgersen:
   Hi,
   
   I started installing godi and ran into a small problem with the
   bootstrap script where the $gmake variable is being set.  I have a shell
   option set that causes the directory being cd'd to to be echoed (not
   sure which shell option this is) and that caused the $gmake variable to
   contain the directory leading to the failure of bootstrap.
   
   This small patch fixed it.
  
  Fix your shell. Many scripts will not work if cd outputs the directory,
  think of constructs like v=$(cd directory; ./start_something).
 
 Yes, this is the problematic case.
 
  I guess cd is an alias to a shell function in your setup, and that the
  alias is set in the wrong initialization file. Such things should only
  be set for interactive shells, and not for any shell.
 
 I agree, but the cd command is neither an alias or a function.  I have
 looked at my .bashrc and .inputrc files and under /etc but I cannot find
 the source of this behaviour. Hmm..

CDPATH? Try unsetting it.

Gerd

 Anders
 
 
  
  Gerd
  -- 
  
  Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
  g...@gerd-stolpmann.de  http://www.gerd-stolpmann.de
  Phone: +49-6151-153855  Fax: +49-6151-997714
  
  
  ___
  Godi-list mailing list
  Godi-list@ocaml-programming.de
  https://godirepo.camlcity.org/mailman/listinfo/godi-list
 
-- 

Gerd Stolpmann, Bad Nauheimer Str.3, 64289 Darmstadt,Germany 
g...@gerd-stolpmann.de  http://www.gerd-stolpmann.de
Phone: +49-6151-153855  Fax: +49-6151-997714


___
Godi-list mailing list
Godi-list@ocaml-programming.de
https://godirepo.camlcity.org/mailman/listinfo/godi-list

Re: [Godi-list] godi-pcre breakage with GODI_BASEPKG_PCRE

2009-12-28 Thread Gerd Stolpmann
Well, that's the wrong order of -lpcre -lpcre_stubs (must be the other
way round for static linking, while for dynamic linking there is no
requirement to give the -l archives in any particular order).

But I fear you are on your own with this issue. There is absolutely no
sensitivity for getting this right among ocaml developers. Even ocaml
itself makes it wrong:

g...@flake:~/tmp$ ocamlc -a -cclib -l1 -cclib -l2 -o t.cma t.cmo
g...@flake:~/tmp$ objinfo t.cma
File t.cma
  Force custom: no
  Extra C object files: -l2 -l1
  ...
g...@flake:~/tmp$ ocamlc -a -cclib -l1 -l2 -o t.cma t.cmo
g...@flake:~/tmp$ objinfo t.cma
File t.cma
  Force custom: no
  Extra C object files: -l2 -l1
  ...

Don't know why the order is not kept. It makes it really hard to
diagnose anything. So far I see, the arguments are again reverted when
the Extra C object files are used.

Anyway, I've fixed that for pcre, but you could run into any number of
similar issues when using libraries. Maybe it is better for you to
define a wrapper for ld that smuggles --start-group and --end-group
options in, so the search for symbols behaves like for shared linking.

Gerd

Am Mittwoch, den 23.12.2009, 16:22 -0600 schrieb Keith Waclena:
 Gerd Stolpmann g...@gerd-stolpmann.de writes:
 
  Peter, thanks for your concise analysis. I've patched godi-pcre as you
  suggest.
 
  Gerd
 
 I've had a problem with godi-pcre for a while now that I've been too
 lazy to post about.  I was hoping this recent change might have fixed
 it but it does not.
 
 My problem is I can no longer statically link any of my ocaml apps
 that use pcre; of course, this includes any of my apps that use
 ocamlnet or pxp, so that's basically all my apps.  I rely heavily on
 statically-linked single-file ocaml executables in order to have
 rock-solid unbreakable ocaml apps that survive OS upgrades and the
 like, and which can be installed with no prerequisites.
 
 I have the same exact problem on all my platforms: Linux, FreeBSD and
 NetBSD (and I think Solaris and Mac OS X, though I haven't tested
 thoroughly on those) and on both 32-bit and 64-bit systems.  Also same
 problem with 3.10 godi install.
 
 Here's what happens when I try to statically link this test app:
 
 let () =
 if Pcre.pmatch ~pat:foo Sys.argv.(1)
 then print_endline match
 else print_endline NO
 
 This is on Linux and I have done a full reinstall of 3.11 with the
 latest rocketboost tarball.
 
 $ ocamlbuild -lib pcre -cflags -I,$(ocamlfind query pcre) -lflags 
 -I,$(ocamlfind query pcre),-cclib,-static pcreproblem.native
 Finished, 0 targets (0 cached) in 00:00:00.
 + ocamlfind ocamlopt -I /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre -cclib 
 -static pcre.cmxa -linkpkg pcreproblem.cmx -o pcreproblem.native
 /usr/app/godi-3.11/lib/ocaml/std-lib/libasmrun.a(unix.o): In function 
 `caml_dlopen':
 unix.c:(.text+0x234): warning: Using 'dlopen' in statically linked 
 applications requires at runtime the shared libraries from the glibc version 
 used for linking
 /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): 
 In function `pcre_dealloc_tables':
 pcre_stubs.c:(.text+0x3): undefined reference to `pcre_free'
 /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): 
 In function `pcre_dealloc_regexp':
 pcre_stubs.c:(.text+0x25): undefined reference to `pcre_free'
 /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): 
 In function `pcre_config_match_limit_stub':
 pcre_stubs.c:(.text+0xaf): undefined reference to `pcre_config'
 /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): 
 In function `pcre_config_stackrecurse_stub':
 pcre_stubs.c:(.text+0xdf): undefined reference to `pcre_config'
 /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): 
 In function `pcre_config_link_size_stub':
 pcre_stubs.c:(.text+0x10f): undefined reference to `pcre_config'
 /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): 
 In function `pcre_config_newline_stub':
 pcre_stubs.c:(.text+0x13f): undefined reference to `pcre_config'
 /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): 
 In function `pcre_config_utf8_stub':
 pcre_stubs.c:(.text+0x16c): undefined reference to `pcre_config'
 /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): 
 In function `pcre_names_stub':
 pcre_stubs.c:(.text+0x23a): undefined reference to `pcre_fullinfo'
 pcre_stubs.c:(.text+0x25c): undefined reference to `pcre_fullinfo'
 pcre_stubs.c:(.text+0x27e): undefined reference to `pcre_fullinfo'
 /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): 
 In function `pcre_lastliteral_stub':
 pcre_stubs.c:(.text+0x437): undefined reference to `pcre_fullinfo'
 /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): 
 In function `pcre_firstbyte_stub':
 

Re: [Godi-list] godi-pcre breakage with GODI_BASEPKG_PCRE

2009-12-28 Thread Keith Waclena
Gerd Stolpmann g...@gerd-stolpmann.de writes:

 Well, that's the wrong order of -lpcre -lpcre_stubs (must be the other
 way round for static linking, while for dynamic linking there is no
 requirement to give the -l archives in any particular order).

Gerd, thanks a million!  Works perfectly again!

 But I fear you are on your own with this issue. There is absolutely no
 sensitivity for getting this right among ocaml developers. Even ocaml
 itself makes it wrong:

 g...@flake:~/tmp$ ocamlc -a -cclib -l1 -cclib -l2 -o t.cma t.cmo
 g...@flake:~/tmp$ objinfo t.cma
 File t.cma
   Force custom: no
   Extra C object files: -l2 -l1
   ...
 g...@flake:~/tmp$ ocamlc -a -cclib -l1 -l2 -o t.cma t.cmo
 g...@flake:~/tmp$ objinfo t.cma
 File t.cma
   Force custom: no
   Extra C object files: -l2 -l1
   ...

 Don't know why the order is not kept. It makes it really hard to
 diagnose anything. So far I see, the arguments are again reverted when
 the Extra C object files are used.

Are you saying this boils down to an ocamlc bug?  Should I report it?

Or, is this a pcre-ocaml bug I should report to Markus?

 Anyway, I've fixed that for pcre, but you could run into any number of
 similar issues when using libraries. Maybe it is better for you to
 define a wrapper for ld that smuggles --start-group and --end-group
 options in, so the search for symbols behaves like for shared linking.

As far as possible I try to avoid using 3rd-party C libraries in my
ocaml code -- I try to stick with pure ocaml libraries.  But there's
no avoiding pcre in what I do.

I would like to understand how you fixed this -- can you point me at
the changes you had to make?  I diffed buildfiles/godi-pcre-6.0.1godi2
and buildfiles/godi-pcre-6.0.1godi4 but I don't think I see the fix in
there.

Thanks again!

___
Godi-list mailing list
Godi-list@ocaml-programming.de
https://godirepo.camlcity.org/mailman/listinfo/godi-list