Re: [tcpdump-workers] build failures on Solaris
--- Begin Message --- Hi Guy, Am 03.08.2021 um 09:26 schrieb Guy Harris : > On Aug 3, 2021, at 12:07 AM, Dagobert Michelsen wrote: > >> The /64 suffix in bin/ and lib/ is a symlink to the respective architecture >> and simplifies cross-platform build between Sparc and x86. > > For whatever reason, /usr/bin/64 isn't present on my Solaris 11.3 (x86-64) VM: > > solaris11$ ls /usr/bin/64 > /usr/bin/64: No such file or directory > solaris11$ uname -a > SunOS solaris11 5.11 11.3 i86pc i386 i86pc > > The same is true of the directory containing the installed-from-IPS gcc: > > solaris11$ which gcc > /usr/ccs/bin/gcc > solaris11$ ls /usr/ccs/bin/64 > /usr/ccs/bin/64: No such file or directory > > and Sun/Oracle C: > > solaris11$ which cc > /opt/developerstudio12.5/bin/cc > solaris11$ ls /opt/developerstudio12.5/bin/64/cc > /opt/developerstudio12.5/bin/64/cc: No such file or directory > > Sun/Oracle don't appear to have made as vigorous an effort to make this work > as OpenCSW have. The reason is probably that it is usually not important if you use the 32 or 64 bit binary - you just want the one that is suitable which was historically done by hardlinking the name to isaexec searching to ISAs from most to least optimal or linker ISA features nowadays. This is obviously not the case for *-config where you want exactly 32 or 64 bit depending on your build ISA. To make things worse Solaris 11 has a mixture of 32 and 64 bit binaries in /bin, but again which most of the time does not make a difference. Best regards — Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] build failures on Solaris
--- Begin Message --- Hi Denis, Am 03.08.2021 um 00:34 schrieb Denis Ovsienko via tcpdump-workers : > Though it is not clear why the 64-bit directories are not in PATH. This is because you need to decide whether you want to build against the 32 or 64 bit ABI. Solaris nowadays always runs a 64 bit kernel but allows programs and libraries to be in 32 bit, although you cannot mix 32 and 64 bit within a linked executable. Of course it would be possible to switch the PATH to be 64 bit only on Solaris 10 but was not done due to historical reasons. On Solaris 11 most binaries are 64 bit now but are located in /usr/bin which makes this thing a bit convoluted. When you try to build a 64 bit binary the correct way is to set PATH and PKG_CONFIG_PATH as described here: https://www.opencsw.org/manual/for-developers/index.html The /64 suffix in bin/ and lib/ is a symlink to the respective architecture and simplifies cross-platform build between Sparc and x86. I hope this helps. Best regards — Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Stick with Travis for continuous integration, or switch?
--- Begin Message --- Hi folks, Am 21.01.2021 um 04:24 schrieb Denis Ovsienko via tcpdump-workers : >> s390x (a/k/a z/Architecture, i.e. S/3x0-64) - a big-endian >> platform, so we can do some testing of operation on big-endian >> machines. Just as a tiny comment: big-endian is also checked on Solaris Sparc with the OpenCSW farm buildbot already hooked up in the Github CI. Best regards — Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0
Hi Denis, Am 24.07.2018 um 10:51 schrieb Denis Ovsienko : > You had this exact discussion 2 weeks ago, didn't you? For the avoidance of > doubt, this thread isn't about voting. Ah right, it did feel like some kind of deja vu but I falsely remembered that to be on a different mailing list. Sorry for the noise! — Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0
Hi Jan,
Am 23.07.2018 um 22:04 schrieb Jan Stary :
>
> From both a sysadmin and user perspective, I find the GNU autotools
> amd CMake a major annoyance. Would you please consider doing what e.g.
> http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does?
>
> A simple, hand written shell script, with a set of obvious
> {test,compat}-*.c helpers. No dependency on anything, orders
> of multitude smaller and faster then a auto*-generated configure.
No - please! Handwritten configure scripts are the worst nightmare for
downstream packages as each package uses its own way to configure flags
for compilation, linkage, install relocation etc. This makes
packaging stuff hard as it requires specific adjustments of build
procedures. I maintain roughly 1600 packages and this would not be
possible when there were no standards. Autotools is far from perfect,
but it is a standard and after you figured something out it works for
hundreds of builds in the same way.
Best regards
— Dago
--
"You don't become great by trying to be great, you become great by wanting to
do something,
and then doing it so hard that you become great in the process." - xkcd #896
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0
Hi, Am 23.07.2018 um 19:11 schrieb Ray Bellis : > On 23/07/2018 17:38, Gert Doering wrote: >> I do understand that this is not for me to decide and that you're >> fully free to ignore me, but I still wanted to say it so nobody can >> say afterwards "hey, we announced this on the list and nobody spoke >> up". > > FWIW, I loath CMake too. :p Is this a vote? It is a real pain to customize parameters in CMake and I avoid it wherever possible and I would really appreciate if autoconf at least won’t go away. Best regards — Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Update configure for libpcap
Hi, Am 12.07.2018 um 12:07 schrieb Jan Stary : > On Jul 11 10:27:50, ghar...@sonic.net wrote: >> I would *personally* prefer that we not have generated configure files in >> Git and require that autoconf be run (or, if it needs to be run with >> particular arguments, supply an autopen.sh file and require that it be run); >> if anybody has an argument against it, let us know. > > The ./configure script does need to be generated in the first place. > I would very much preffer we have a simple, hand-written ./configure, > and avoid the GNU auto* hell altogether, much like e.g. the extremely > portable http://mandoc.bsd.lv/ does. As a non-Linux distro maintainer (OpenCSW for Solaris) I can tell you that „hand-written“ configure scripts are the worst you can get as every package then uses a different approach and it takes a lot of time to figure out the standard things like compiler selection, flags for preprocessor, compiler and linker, install relocation, etc. - if this is taken cared of at all. I don’t say autotools is perfect, by far it is not, but it is a standard and you need to figure out stuff only once and then reuse it for all packages that use this tool. I personally maintain ~1600 packages, with manually written configure scripts this would just not be doable. Just my 0,02€, there may be more important reasons to change the configure mechanism, but for me autotools works pretty good for most of the upstream software I package. Maybe adjusting the configure.ac to be more flexible is a netter approach than reinvfenting the wheel once again. Best regards — Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
