Re: [Godi-list] godi-pcre breakage with GODI_BASEPKG_PCRE
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
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
Re: [Godi-list] godi-pcre breakage with GODI_BASEPKG_PCRE
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': pcre_stubs.c:(.text+0x4f7): undefined reference to `pcre_fullinfo' /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o):pcre_stubs.c:(.text+0x5e7): more undefined references to `pcre_fullinfo' follow /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): In function `pcre_get_stringnumber_stub': pcre_stubs.c:(.text+0xa39): undefined reference to `pcre_get_stringnumber' /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): In function `pcre_maketables_stub': pcre_stubs.c:(.text+0xab0): undefined reference to `pcre_maketables' /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): In function `pcre_exec_stub': pcre_stubs.c:(.text+0xe02): undefined reference to `pcre_exec' pcre_stubs.c:(.text+0xea5): undefined reference to `pcre_exec' /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): In function `pcre_firsttable_stub': pcre_stubs.c:(.text+0x116e): undefined reference to `pcre_fullinfo' /usr/app/godi-3.11/lib/ocaml/pkg-lib/pcre/libpcre_stubs.a(pcre_stubs.o): In function `pcre_study_stub': pcre_stubs.c:(.text+0x12f5): undefined reference to `pcre_study'
Re: [Godi-list] godi-pcre breakage with GODI_BASEPKG_PCRE
Peter, thanks for your concise analysis. I've patched godi-pcre as you
suggest.
Gerd
Am Mittwoch, den 16.12.2009, 00:00 + schrieb Peter:
Back in March there was a thread Latest godi-pcre upgrade breaks
godi-pxp discussing a problem whereby ocamlmklib was forgetting to link
to libpcre when building godi-pcre using GODI_BASEPKG_PCRE. The thread
ended when a workaround was found, and it appears the underlying bug is
still present to this day.
Note that the problem does not simply break godi-pxp. It breaks *all*
bytecode usage of godi-pcre on affected platforms, including the
installation of packages such as godi-mikmatch_pcre.
The reason the correct flags are not passed to ocamlmklib turns out to
be that godi_make is clobbering OCAMLMKLIB_FLAGS by passing its own
value on the gmake command line. When pcre-ocaml's lib/Makefile tries
to add the output from pcre-config to this variable, gmake silently
ignores it because the command-line value takes precedence.
The simplest solution seems to be to modify godi-pcre's Makefile so that
it uses a different variable, and patch pcre-ocaml/lib/Makefile to
include the GODI value when setting OCAMLMKLIB_FLAGS. This should work
regardless of the setting of GODI_BASEPKG_PCRE. In other words,
something along the lines of:
--- ../old/Makefile 2009-12-15 22:10:44.0 +
+++ ./Makefile2009-12-15 23:05:12.0 +
@@ -46,7 +46,7 @@
.endif
.if ${CONF_PCRE_NEED_RPATH} == yes
-MAKE_FLAGS+= OCAMLMKLIB_FLAGS=-Wl,${RPATH_FLAG}${CONF_PCRE_LIBDIR}
+MAKE_FLAGS+= GODI_MKLIB_FLAGS=-Wl,${RPATH_FLAG}${CONF_PCRE_LIBDIR}
.endif
USE_GMAKE= yes
--- ../old/patches/patch-aa-lib_Makefile 1970-01-01 01:00:00.0
+0100
+++ ./patches/patch-aa-lib_Makefile 2009-12-15 23:04:46.0 +
@@ -0,0 +1,11 @@
+--- lib/Makefile.orig2009-12-15 22:55:05.0 +
lib/Makefile 2009-12-15 22:55:52.0 +
+@@ -4,7 +4,7 @@
+ CFLAGS := -O2 $(shell pcre-config --cflags)
+ PCRE_FLAGS := $(shell pcre-config --libs)
+ OCAMLLDFLAGS := -cclib $(PCRE_FLAGS)
+-OCAMLMKLIB_FLAGS := $(PCRE_FLAGS)
++OCAMLMKLIB_FLAGS := $(GODI_MKLIB_FLAGS) $(PCRE_FLAGS)
+ RESULT := pcre
+
+ all:
___
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
