[Buildroot] [PATCH V2 1/2] tcl: add support for static builds

[Buildroot] [PATCH V2 1/2] tcl: add support for static builds

[Vicente Olivert Riera]

tcl fails to build statically for two reasons. The first one is because
it tries to build the tclsh binary with dynamic loading support, which
uses dlopen() and friends. This is because the '--enable-load' configure
option is 'on' by default. The second one is because it builds the
'packages' by default. These 'packages' are shared objects which are
intended to be loaded dynamically.

In order to fix this, we add '--disable-load' to the configure options
and avoid building the 'packages' when BR2_STATIC_LIBS is set.

Related upstream mailing list thread:

  http://sourceforge.net/p/tcl/mailman/message/33388034/

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
Changes V1 -> V2: Remove HOST_TCL stuff

 package/tcl/tcl.mk |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/package/tcl/tcl.mk b/package/tcl/tcl.mk
index 1ebba1e..0c328ee 100644
--- a/package/tcl/tcl.mk
+++ b/package/tcl/tcl.mk
@@ -29,6 +29,18 @@ HOST_TCL_CONF_OPTS = \
 	--disable-langinfo \
 	--disable-framework
 
+ifeq ($(BR2_STATIC_LIBS),y)
+# Do not build tclsh with dynamic loading support when building it
+# statically because it needs dlopen() and friends.
+TCL_CONF_OPTS += --disable-load
+# Also, build only the binaries and libraries and don't build the
+# 'packages' because they are shared objects which are intended to be
+# loaded dynamically.
+TCL_MAKE_OPTS = binaries libraries
+TCL_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR) install-binaries install-libraries
+TCL_INSTALL_TARGET_OPTS = DESTDIR=$(TARGET_DIR) install-binaries
+endif
+
 # I haven't found a good way to force pkgs to not build
 # or configure without just removing the entire pkg directory.
 define HOST_TCL_REMOVE_PACKAGES
-- 
1.7.1

[Buildroot] [PATCH V2 2/2] tcl: rename BR2_PACKAGE_TCL_SHLIB_ONLY to be more consistent

[Vicente Olivert Riera]

The BR2_PACKAGE_TCL_SHLIB_ONLY is confusing because someone could think
that only shared libraries would be installed. But, what actually does
is removing the 'tclsh' binary, so better to reword it in order to be
consistent with what actually does.

Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
---
Changes V1 -> V2: add an entry to Config.in.legacy

 Config.in.legacy      |   12 ++++++++++++
 package/tcl/Config.in |    7 +++----
 package/tcl/tcl.mk    |    2 +-
 3 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/Config.in.legacy b/Config.in.legacy
index 0b87ddb..9a48045 100644
--- a/Config.in.legacy
+++ b/Config.in.legacy
@@ -100,6 +100,18 @@ endif
 
 ###############################################################################
 
+config BR2_PACKAGE_TCL_SHLIB_ONLY
+	string "tcl: the 'install only shared library' option has been renamed"
+	help
+	  The option BR2_PACKAGE_TCL_SHLIB_ONLY has been renamed to
+	  BR2_PACKAGE_TCL_REMOVE_TCLSH to be consistent with what it
+	  does.
+
+config BR2_PACKAGE_TCL_SHLIB_ONLY_WRAP
+	bool
+	default y if BR2_PACKAGE_TCL_SHLIB_ONLY != ""
+	select BR2_LEGACY
+
 comment "Legacy options removed in 2015.02"
 
 config BR2_PACKAGE_LIBGC
diff --git a/package/tcl/Config.in b/package/tcl/Config.in
index c3d0d87..996dc96 100644
--- a/package/tcl/Config.in
+++ b/package/tcl/Config.in
@@ -25,12 +25,11 @@ config BR2_PACKAGE_TCL_DEL_ENCODINGS
 
 	  It saves approx. 1.6 Mb of space.
 
-config BR2_PACKAGE_TCL_SHLIB_ONLY
-	bool "install only shared library"
+config BR2_PACKAGE_TCL_REMOVE_TCLSH
+	bool "do not install tclsh"
 	default y
 	help
-	  Install only TCL shared library and not binary tcl
-	  interpreter (tclsh).
+	  Do not install the tcl interpreter (tclsh).
 
 	  Saves ~14kb.
 
diff --git a/package/tcl/tcl.mk b/package/tcl/tcl.mk
index 0c328ee..5d851f3 100644
--- a/package/tcl/tcl.mk
+++ b/package/tcl/tcl.mk
@@ -69,7 +69,7 @@ endef
 TCL_POST_INSTALL_TARGET_HOOKS += TCL_REMOVE_ENCODINGS
 endif
 
-ifeq ($(BR2_PACKAGE_TCL_SHLIB_ONLY),y)
+ifeq ($(BR2_PACKAGE_TCL_REMOVE_TCLSH),y)
 define TCL_REMOVE_TCLSH
 	rm -f $(TARGET_DIR)/usr/bin/tclsh$(TCL_VERSION_MAJOR)
 endef
-- 
1.7.1

[Buildroot] [PATCH V2 1/2] tcl: add support for static builds

[Thomas Petazzoni]

Dear Vicente Olivert Riera,

On Sat, 7 Mar 2015 13:22:41 +0000, Vicente Olivert Riera wrote:

> +ifeq ($(BR2_STATIC_LIBS),y)
> +# Do not build tclsh with dynamic loading support when building it
> +# statically because it needs dlopen() and friends.
> +TCL_CONF_OPTS += --disable-load
> +# Also, build only the binaries and libraries and don't build the
> +# 'packages' because they are shared objects which are intended to be
> +# loaded dynamically.
> +TCL_MAKE_OPTS = binaries libraries
> +TCL_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR) install-binaries install-libraries
> +TCL_INSTALL_TARGET_OPTS = DESTDIR=$(TARGET_DIR) install-binaries
> +endif

But, if we don't build the 'packages', is the tcl stuff still useful?

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH V2 2/2] tcl: rename BR2_PACKAGE_TCL_SHLIB_ONLY to be more consistent

[Thomas Petazzoni]

Dear Vicente Olivert Riera,

On Sat, 7 Mar 2015 13:22:42 +0000, Vicente Olivert Riera wrote:

> +config BR2_PACKAGE_TCL_SHLIB_ONLY
> +	string "tcl: the 'install only shared library' option has been renamed"
> +	help
> +	  The option BR2_PACKAGE_TCL_SHLIB_ONLY has been renamed to
> +	  BR2_PACKAGE_TCL_REMOVE_TCLSH to be consistent with what it
> +	  does.
> +
> +config BR2_PACKAGE_TCL_SHLIB_ONLY_WRAP
> +	bool
> +	default y if BR2_PACKAGE_TCL_SHLIB_ONLY != ""
> +	select BR2_LEGACY

The 'wrap' thing is only when removing string options, not boolean
options.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH V2 1/2] tcl: add support for static builds

[Vicente Olivert Riera]

Dear Thomas Petazzoni,

On 07/03/15 14:42, Thomas Petazzoni wrote:
> Dear Vicente Olivert Riera,
> 
> On Sat, 7 Mar 2015 13:22:41 +0000, Vicente Olivert Riera wrote:
> 
>> +ifeq ($(BR2_STATIC_LIBS),y)
>> +# Do not build tclsh with dynamic loading support when building it
>> +# statically because it needs dlopen() and friends.
>> +TCL_CONF_OPTS += --disable-load
>> +# Also, build only the binaries and libraries and don't build the
>> +# 'packages' because they are shared objects which are intended to be
>> +# loaded dynamically.
>> +TCL_MAKE_OPTS = binaries libraries
>> +TCL_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR) install-binaries install-libraries
>> +TCL_INSTALL_TARGET_OPTS = DESTDIR=$(TARGET_DIR) install-binaries
>> +endif
> 
> But, if we don't build the 'packages', is the tcl stuff still useful?

I guess you could need tcl to build something that depends on it, and
link against libtcl8.6.a, for instance.

Regards,
--
Vincent

> Best regards,
> 
> Thomas
> 

[Buildroot] [PATCH V2 1/2] tcl: add support for static builds

[Thomas Petazzoni]

Dear Vicente Olivert Riera,

On Sat, 7 Mar 2015 15:28:50 +0100, Vicente Olivert Riera wrote:

> I guess you could need tcl to build something that depends on it, and
> link against libtcl8.6.a, for instance.

If you need tcl to build something, then it's the host tcl, not the
target tcl.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH V2 1/2] tcl: add support for static builds

[Vicente Olivert Riera]

Dear Thomas Petazzoni,


On 07/03/15 15:56, Thomas Petazzoni wrote:
> Dear Vicente Olivert Riera,
> 
> On Sat, 7 Mar 2015 15:28:50 +0100, Vicente Olivert Riera wrote:
> 
>> I guess you could need tcl to build something that depends on it, and
>> link against libtcl8.6.a, for instance.
> 
> If you need tcl to build something, then it's the host tcl, not the
> target tcl.

uhm..., I'm sorry but I don't understand what you mean.

If you have a package that depends on tcl (it links against libtcl8.6.a,
for instance), then you will need the target tcl (actually the staging
one), which has the right architecture for your target, no? The host tcl
would have the same architecture as the host machine which may not be
the same as the target one.

Am I missing anything?

Regards,
--
Vincent


> Thomas
> 

[Buildroot] [PATCH V2 1/2] tcl: add support for static builds

[Thomas Petazzoni]

Dear Vicente Olivert Riera,

On Sat, 7 Mar 2015 16:05:17 +0100, Vicente Olivert Riera wrote:

> If you have a package that depends on tcl (it links against libtcl8.6.a,
> for instance), then you will need the target tcl (actually the staging
> one), which has the right architecture for your target, no? The host tcl
> would have the same architecture as the host machine which may not be
> the same as the target one.
> 
> Am I missing anything?

Yes: you still haven't answered whether the 'packages' thing in TCL is
important or not. Yes, your tcl static linking thing is *building*
properly. But does it work? Does the result actually make sense? You've
solved the static linking case by simply not building everything. What
guarantees you that the result is something that works?

Since it seems you actually don't know what TCL is and how it works
(and neither do I), I'd prefer to mark it !BR2_STATIC_LIBS, and let
someone actually interested in using TCL in a statically linked
scenario take care of implementing this.

Thanks,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH V2 1/2] tcl: add support for static builds

[Vicente Olivert Riera]

Dear Thomas Petazzoni,

On 07/03/15 16:35, Thomas Petazzoni wrote:
> Dear Vicente Olivert Riera,
> 
> On Sat, 7 Mar 2015 16:05:17 +0100, Vicente Olivert Riera wrote:
> 
>> If you have a package that depends on tcl (it links against libtcl8.6.a,
>> for instance), then you will need the target tcl (actually the staging
>> one), which has the right architecture for your target, no? The host tcl
>> would have the same architecture as the host machine which may not be
>> the same as the target one.
>>
>> Am I missing anything?
> 
> Yes: you still haven't answered whether the 'packages' thing in TCL is
> important or not. Yes, your tcl static linking thing is *building*
> properly. But does it work? Does the result actually make sense? You've
> solved the static linking case by simply not building everything. What
> guarantees you that the result is something that works?
> 
> Since it seems you actually don't know what TCL is and how it works
> (and neither do I), I'd prefer to mark it !BR2_STATIC_LIBS, and let
> someone actually interested in using TCL in a statically linked
> scenario take care of implementing this.

Ok, no problem.

Regards,
--
Vincent

> Thanks,
> 
> Thomas
> 

[Buildroot] [PATCH V2 1/2] tcl: add support for static builds

[Arnout Vandecappelle]

On 07/03/15 14:42, Thomas Petazzoni wrote:
> Dear Vicente Olivert Riera,
> 
> On Sat, 7 Mar 2015 13:22:41 +0000, Vicente Olivert Riera wrote:
> 
>> +ifeq ($(BR2_STATIC_LIBS),y)
>> +# Do not build tclsh with dynamic loading support when building it
>> +# statically because it needs dlopen() and friends.
>> +TCL_CONF_OPTS += --disable-load
>> +# Also, build only the binaries and libraries and don't build the
>> +# 'packages' because they are shared objects which are intended to be
>> +# loaded dynamically.
>> +TCL_MAKE_OPTS = binaries libraries
>> +TCL_INSTALL_STAGING_OPTS = DESTDIR=$(STAGING_DIR) install-binaries install-libraries
>> +TCL_INSTALL_TARGET_OPTS = DESTDIR=$(TARGET_DIR) install-binaries
>> +endif
> 
> But, if we don't build the 'packages', is the tcl stuff still useful?

 The packages are a bunch of additional packages that happen to be distributed
together with tcl. In this case:

incr Tcl (object-oriented extensions)
sqlite
thread
tdbc (database connector)

 So if you want to run scripts that make use of these packages, yes you're in
trouble. But I expect that there will be plenty of scripts that don't use these
extensions.


 That said, I agree with Thomas's final statement that unless you're actually
using this, it's both pointless and dangerous to make such a change.


 Regards,
 Arnout


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F