This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
"Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> writes: > Perhaps the target expert isn't too familiar with gcc sources. In that > case, she can get help on gcc@gcc.gnu.org. The problem is that this is causing much more pain than necessary. Adding something to gcc is hard. There are so many things to take care of since so many files are shared by many architecture. Standaline packages don't have this problem. > If his proposal was to provide a -fPIC libgcc object file collection > which is transformed into a shared library during glibc installation - > that won't work. I don't think users will want to rebuild glibc as > part of gcc installation. I don't think this works either. This is my I'm currently favouring a standaline package. But there might be situation where a new libc might require a new version of the libgcc.so and therefore there must be some kind of coupling between this new package and glibc. Perhaps something like an add-on (in the glibc-sense) which can also be used standalone).
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |