Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!panix!.POSTED.localhost!not-for-mail From: Grant Edwards Newsgroups: comp.arch.embedded Subject: Re: 32 bits time_t and Y2038 issue Date: Sat, 15 Mar 2025 17:02:04 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: References: Injection-Date: Sat, 15 Mar 2025 17:02:04 -0000 (UTC) Injection-Info: reader1.panix.com; posting-host="localhost:::1"; logging-data="1936"; mail-complaints-to="abuse@panix.com" User-Agent: slrn/1.0.3 (Linux) Xref: csiph.com comp.arch.embedded:32365 On 2025-03-15, Michael Schwingen wrote: > On 2025-03-11, David Brown wrote: >> package as-is. For anything other than a quick demo, my preferred setup >> is using makefiles for the build along with an ARM gcc toolchain. That >> way I can always build my software, from any system, and archive the >> toolchain. (One day, I will also try using clang with these packages, >> but I haven't done so yet.) > > Same here. I just switched to ARM gcc + picolibc for all my ARM projects - > this required some changes in the way my makefiles generate linker scripts > and startup code, and now I am quite happy with that setup. Yep. IMO, that's definitely the "One True Answer" for embedded development. I worked with a guy who wanted to use Eclipse for embedded development. After _months_ of f&*king around, he was finally able to build a binary that worked. But trying to build that Eclipse "project" on another computer (same OS, same version of Eclips, same toolchain) was a complete failure. I finally told him it was fine if he wanted to use Eclipse as his editor, gdb front-end, SVN gui, filesystem browser, office-cleaner and nose-wiper. But it was a non-negotiable requirement that it be possible to check the source tree and toolchain out of SVN, type "make", hit enter, and end up with a working binary. -- Grant