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 <[hidden email]> 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 <[hidden email]> wrote: > > > >> On 7. Jul 2017, at 01:13, Tobias Pape <[hidden email]> 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 <[hidden email]> 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. _,,,^..^,,,_ best, Eliot |
> On 7. Jul 2017, at 18:31, Eliot Miranda <[hidden email]> 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 |
In reply to this post by Eliot Miranda-2
> On 07.07.2017, at 18:31, Eliot Miranda <[hidden email]> wrote: > > Hi Tobias, > > On Thu, Jul 6, 2017 at 4:47 PM, Tobias Pape <[hidden email]> wrote: > > > > On 07.07.2017, at 01:14, Holger Freyther <[hidden email]> wrote: > > > > > > > >> On 7. Jul 2017, at 01:13, Tobias Pape <[hidden email]> 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 |
In reply to this post by Holger Freyther
Hi Holger, > On Jul 7, 2017, at 12:00 PM, Holger Freyther <[hidden email]> wrote: > > > >> On 7. Jul 2017, at 18:31, Eliot Miranda <[hidden email]> 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 |
Free forum by Nabble | Edit this page |