Wanted to produce a new 'fat' SqueakSSL binary that's guaranteed to run on both CentOS-like and Debian-like. But no, libtool messes up my linker command line. A bug known since 2006[1]. So, no new SqueakSSL with host name verification for you today…
Now I'm sad and go to bed. -t
[1]: really: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=347650
On 7. Jul 2017, at 01:13, Tobias Pape Das.Linux@gmx.de wrote:
Wanted to produce a new 'fat' SqueakSSL binary that's guaranteed to run on both CentOS-like and Debian-like. But no, libtool messes up my linker command line. A bug known since 2006[1]. So, no new SqueakSSL with host name verification for you today…
Did you try make configure in the unix directory to generate a newer configure/libtool?
holger
On 07.07.2017, at 01:14, Holger Freyther holger@freyther.de wrote:
On 7. Jul 2017, at 01:13, Tobias Pape Das.Linux@gmx.de wrote:
Wanted to produce a new 'fat' SqueakSSL binary that's guaranteed to run on both CentOS-like and Debian-like. But no, libtool messes up my linker command line. A bug known since 2006[1]. So, no new SqueakSSL with host name verification for you today…
Did you try make configure in the unix directory to generate a newer configure/
yes, no change.
holger
Hi Tobias,
On Thu, Jul 6, 2017 at 4:47 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 07.07.2017, at 01:14, Holger Freyther holger@freyther.de wrote:
On 7. Jul 2017, at 01:13, Tobias Pape Das.Linux@gmx.de wrote:
Wanted to produce a new 'fat' SqueakSSL binary that's guaranteed to run
on both
CentOS-like and Debian-like. But no, libtool messes up my linker
command line.
A bug known since 2006[1]. So, no new SqueakSSL with host name
verification for you today…
Did you try make configure in the unix directory to generate a newer
configure/
yes, no change.
I'd really like to see the linux builds take the same approach as the Mac OS X and WIN32/WIN64 builds, just using makefiles and relegating the configure step to create a config.h defining the platform's facilities. Then you ow;don't be dependent on libel. Do you have any energy to take this approach? It would take a few days, but it would be great to say goodbye to the current unix/linux build system.
_,,,^..^,,,_ best, Eliot
On 7. Jul 2017, at 18:31, Eliot Miranda eliot.miranda@gmail.com wrote:
I'd really like to see the linux builds take the same approach as the Mac OS X and WIN32/WIN64 builds, just using makefiles and relegating the configure step to create a config.h defining the platform's facilities. Then you ow;don't be dependent on libel. Do you have any energy to take this approach? It would take a few days, but it would be great to say goodbye to the current unix/linux build system.
please consider what it takes to get a source package into a Linux distribution. E.g. downloading sources at build time is not allowed for most of them (maybe even actively forbidden), and bundling of libraries is generally discouraged. As far as I remember these were two of the attributes when trying to build the macOS VM during one of my last flights. ;)
holger
Hi Holger,
On Jul 7, 2017, at 12:00 PM, Holger Freyther holger@freyther.de wrote:
On 7. Jul 2017, at 18:31, Eliot Miranda eliot.miranda@gmail.com wrote:
I'd really like to see the linux builds take the same approach as the Mac OS X and WIN32/WIN64 builds, just using makefiles and relegating the configure step to create a config.h defining the platform's facilities. Then you ow;don't be dependent on libel. Do you have any energy to take this approach? It would take a few days, but it would be great to say goodbye to the current unix/linux build system.
please consider what it takes to get a source package into a Linux distribution. E.g. downloading sources at build time is not allowed for most of them (maybe even actively forbidden), and bundling of libraries is generally discouraged. As far as I remember these were two of the attributes when trying to build the macOS VM during one of my last flights. ;)
While the Pharo build (which is not mine to define) does download source for support libraries (cairo etc), Squeak and newspeak builds do not.
But how one builds a complex system without either building or bundling libraries I don't know.
In any case this is orthogonal to rewriting the build system to use static makefiles instead of the complex multi-staged generation in platforms/unix/conf. I want the build system in unix to be simpler and more maintainable. That shouldn't change the source of the build at all.
holger
On 07.07.2017, at 18:31, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tobias,
On Thu, Jul 6, 2017 at 4:47 PM, Tobias Pape Das.Linux@gmx.de wrote:
On 07.07.2017, at 01:14, Holger Freyther holger@freyther.de wrote:
On 7. Jul 2017, at 01:13, Tobias Pape Das.Linux@gmx.de wrote:
Wanted to produce a new 'fat' SqueakSSL binary that's guaranteed to run on both CentOS-like and Debian-like. But no, libtool messes up my linker command line. A bug known since 2006[1]. So, no new SqueakSSL with host name verification for you today…
Did you try make configure in the unix directory to generate a newer configure/
yes, no change.
I'd really like to see the linux builds take the same approach as the Mac OS X and WIN32/WIN64 builds, just using makefiles and relegating the configure step to create a config.h defining the platform's facilities. Then you ow;don't be dependent on libel. Do you have any energy to take this approach? It would take a few days, but it would be great to say goodbye to the current unix/linux build system.
I understand this position. So, we both don't like the current situation, but we have still different opinions on a good solution. I don't have the energy to dive into a solution wouldn't support fullheartedly. I hope you understand, no intent to upset anyone. Besides that, building SqueakSSL static and with special link options would only be necessary for Non-Distro-specific Builds, like the ones we have now. Debian/CentOS-integrated builds (wich we really should commence…) should never statically link if possible…
Best regards -Tobias
vm-dev@lists.squeakfoundation.org