Re: Build breaking on autoreconf
Jeff Johnston <[email protected]>
| Newsgroups | gmane.comp.lib.newlib |
|---|---|
| Message-ID | <CAOox84vjXuR8VBEaaR7GFpLo4A+MGg+ZARtbXruxhOPf4f-VnA@mail.gmail.com> |
Hi Tom, You will need to provide exactly what you specify on configure (and where) so people can comment. You need to configure from the top-level directory and use make all-target-newlib. There are macro settings provided by the top-level configure. Regarding the libm_a prefixes, this is due to the specification of libm_a_SOURCES in the Makefile.inc files in libm. Automake will prefix the objects created from these sources with libm_a- . This makes sense as you might have multiple targets being created (e.g. libm.a, libmath.a) using common files but compiled with different flags so automake needs to be able to refer to them properly for linking, etc.. Not sure what you are referring to with %fs. If you want information about reentrancy/threads, see: newlib/libc/reent.h. Single threaded applications still use an internal reentrancy structure, but you don't have to manage it or even know about it unless you write syscalls. Your configuration options for running single thread are fine. You don't need to specify disable thread local as the default is no, but no issues in specifying it directly. -- Jeff J. On Thu, Aug 29, 2024 at 9:29 AM Kuchler Tom <[email protected]> wrote: > Hi Jeff, > > I just used linux as a minimal reproducible example, but maybe that was a > bad choice. > In the mean time I have found what causes the issue. > In newlib/Makfile.am the MATHOBJS_IN_LIBC all have a prefix `libm_` which > was not on the actual file names, so if I remove them, everything compiles > for my own OS implementation. > > On another note, I see a lot of use of %fs in the compiled library on > x86_64, as far as I know this is supposed to be for thread local storage. > I have the options --disable-newlib-reent-thread-local and > --disable-newlib-multithread, is thread local storage also used in single > threaded mode? > > Or could it be I just haven't configured it correctly? > The docs describe which OS functions I need to provide, but there seem to > be some additional things that need to be set up for it to work. > I'm trying to figure out what the expected environment is. > > Thanks a lot for your help, > > Tom > > > ------------------------------ > *Von:* Jeff Johnston <[email protected]> > *Gesendet:* Dienstag, 27. August 2024 01:00:32 > *An:* Kuchler Tom > *Cc:* [email protected] > *Betreff:* Re: Build breaking on autoreconf > > Hi Tom, > > It appears you are trying to build newlib for x86_64-linux. This is a > special configuration since newlib is built cross-platform and skipped for > the host platform (gcc is the one to use when you have no cross-platform > issues > to consider). gcc also supports Linux syscalls and has a much larger set > of functionality. As you have noted, configuration should occur from the > top-level directory. When you are building a native newlib, you have to > specify: --with-newlib as an extra configuration parameter, otherwise > newlib is skipped. > > That said, there used to be host newlib support for i[3456]86-linux that > used linux syscalls and had additional functionality compared to basic > newlib, but that has been removed as it used a combination of host C > headers and newlib headers that broke whenever gcc changed the headers. As > for a straight host newlib, it is not officially supported. For example, > there is no support in libgloss to supply syscalls or start up code > (crt0.S). You might be able to bolt together something yourself or use > libnosys to get stub syscalls. > > -- Jeff J. > > On Wed, Aug 21, 2024 at 12:40 PM Kuchler Tom <[email protected]> > wrote: > >> Dear maintainers, >> >> I was trying to port newlib to an OS I'm working on and ran into an issue >> with autoreconf. >> When I was looking into it it seems that it is an issue with the current >> newlib, but may be that it is also me not understanding autoreconf. >> >> My current suspicion is that it is probably a user failure on my side, >> but I can't find anything related that is up to date with the new version, >> so I though I'd ask if this is expected behavior and how I should fix it or >> let you know about it in case it is not expected behavior. >> >> The issue I ran into is that stamp-libc-math-objects fails with ar errors >> as in the error log attached. >> I cloned the code from https://sourceware.org/git/newlib-cygwin.git and >> it happens on the latest cygwin release (3.5.3) but I also checked it on >> newlib-4.4.0 and newlib-4.3.0 >> I make a new folder next to the cloned folder and execute >> ../newlib-cygwin/newlib/configure --host=x86_64-linux && make all >> With a fresh clone the build finishes without any errors. >> If I run autoreconf in the top level directory it still builds, but if I >> run it in newlib-cygwin/newlib then it breaks. >> >> I use the recommended version 2.69 of autoreconf. >> I also saw in the FAQ that the configuration is supposed to happen from >> the top level folder, but if I do that it does not build anything at all, >> so that might be an issue, >> >> but it still works if I don't run autoreconf which is what confuses me. >> >> Best regards, >> Tom >> >>