On Fri, Feb 02, 2024 at 10:48:54PM +0200, Konstantin Belousov wrote:
> On Fri, Feb 02, 2024 at 12:07:35PM -0800, Steve Kargl wrote:
> >
> > Thanks for the explanation, but I think I now have a conundrum.
> > Suppose I have two shared libraries libfoo.so and libbar.so, and
> > suppose bah@@XXX_1.0
On Fri, Feb 02, 2024 at 12:07:35PM -0800, Steve Kargl wrote:
> On Sun, Jan 28, 2024 at 12:04:48PM +0200, Konstantin Belousov wrote:
> > On Sat, Jan 27, 2024 at 09:22:59PM -0800, Steve Kargl wrote:
> > > On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote:
> > > > On 27 Jan 2024, at 18:08
On Sun, Jan 28, 2024 at 12:04:48PM +0200, Konstantin Belousov wrote:
> On Sat, Jan 27, 2024 at 09:22:59PM -0800, Steve Kargl wrote:
> > On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote:
> > > On 27 Jan 2024, at 18:08, Steve Kargl
> > > wrote:
> > > >
> > > > In an attempt to cleanu
On Sat, Jan 27, 2024 at 09:22:59PM -0800, Steve Kargl wrote:
> On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote:
> > On 27 Jan 2024, at 18:08, Steve Kargl
> > wrote:
> > >
> > > In an attempt to cleanup a bit of src/lib/msun, I ran into
> > > a small issue that I cannot explain at
On Sat, Jan 27, 2024 at 10:29:34PM +0100, Dimitry Andric wrote:
> On 27 Jan 2024, at 18:08, Steve Kargl
> wrote:
> >
> > In an attempt to cleanup a bit of src/lib/msun, I ran into
> > a small issue that I cannot explain at the moment. If I have
> > /usr/bin/ld in my path prior to /usr/local/bin
On 27 Jan 2024, at 18:08, Steve Kargl wrote:
>
> In an attempt to cleanup a bit of src/lib/msun, I ran into
> a small issue that I cannot explain at the moment. If I have
> /usr/bin/ld in my path prior to /usr/local/bin/ld everything
> works
>
> % which ld
> /usr/bin/ld
> % make clean && make c
In an attempt to cleanup a bit of src/lib/msun, I ran into
a small issue that I cannot explain at the moment. If I have
/usr/bin/ld in my path prior to /usr/local/bin/ld everything
works
% which ld
/usr/bin/ld
% make clean && make cleandepend
% make
and I have a libm.so.5. But if /usr/local/bin
On Mon, 26 Nov 2018 at 10:52, Ed Maste wrote:
>
> The most significant issue is
> sys/crypto/skein/amd64/skein_block_asm.s, and it makes extensive use
> of GNU macro extensions. I have looked at nasm and yasm but believe
> the macro extension support in those is less developed than in Clang's
> IA
On Sat, 24 Nov 2018 at 17:24, Charlie Li wrote:
>
> some Makefile logic in stand/i386/btx specify a
> hard-coded /usr/bin/as without bootstrapped binutils, necessitating a
> symlink.
Which logic specifically? I can't seem to find it.
> If it is true that the only assembly
On Sun, 25 Nov 2018 at 07:52, David Chisnall wrote:
>
> We probably need to kill ld.bfd before 12.0. It predates ifunc and so
> interprets anything with an ifunc as requiring a copy relocation.
I posted https://reviews.freebsd.org/D18340 to stop installing ld.bfd
when LLD_IS_LD is enabled. This
On 23 Nov 2018, at 16:23, Ed Maste wrote:
>
> For some time we have been incrementally working to retire the use of
> obsolete GNU Binutils 2.17.50 tools. At present we still install three
> binutils by default:
>
> as
> ld.bfd
> objdump
We probably need to kill
witch to using IAS for all assembly files, and if
> not we could rewrite the few assembly files to work with IAS.
>
I've been using the port binutils as for quite some time on amd64 (with
WITHOUT_BINUTILS and WITHOUT_BINUTILS_BOOTSTRAP) with success by
specifying XAS, although some
For some time we have been incrementally working to retire the use of
obsolete GNU Binutils 2.17.50 tools. At present we still install three
binutils by default:
as
ld.bfd
objdump
The intent is to retire all of these by FreeBSD 13. Depending on tool
and architecture we will just remove it
gt;>> BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail
>>> /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276
>>>
>>> The kernel has been built on 11.1 with LD=/usr/bin/ld.lld
>>>
>>> Is this something that matt
On Wed, 24 Oct 2018, John Baldwin wrote:
> On 10/23/18 10:58 AM, Marcin Cieslak wrote:
> > This GDB was configured as "amd64-marcel-freebsd"...BFD:
> > /boot/kernel/kernel: invalid relocation type 37
> > BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail
&g
ebsd"...BFD: /boot/kernel/kernel:
> invalid relocation type 37
> BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail
> /usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276
>
> The kernel has been built on 11.1 with LD=/usr/bin/ld.lld
>
>
to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...BFD: /boot/kernel/kernel:
invalid relocation type 37
BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail
/usr/s
On Sun, Mar 4, 2018, at 02:38, Ed Maste wrote:
> On 2 March 2018 at 04:34, Tobias Kortkamp wrote:
> > Building pkgbase packages with r330236 results in FreeBSD-binutils and
> > FreeBSD-lld packages conflicting with each other. Both want to
> > install /usr/share/man/man1/ld
On 2 March 2018 at 04:34, Tobias Kortkamp wrote:
> Building pkgbase packages with r330236 results in FreeBSD-binutils and
> FreeBSD-lld packages conflicting with each other. Both want to
> install /usr/share/man/man1/ld.1.gz
Thanks for the report; this should be fixed as o
Building pkgbase packages with r330236 results in FreeBSD-binutils and
FreeBSD-lld packages conflicting with each other. Both want to
install /usr/share/man/man1/ld.1.gz
For now I'm working around it by manually extracting FreeBSD-lld.
FreeBSD-binutils should install its man page as ld.bfd
It turns out that svn commit: r325320
breaks lld.
lld has code that uses fallocate and
now can fail (stop the link) on zfs.
I've sent a separate reply to the
notice below that gives the details.
I added the [...] part of the title.
Re: svn commit: r325320 - head/sys/cddl/contrib/opensolaris/uts
[Top post: contrast with a combination
using aarch64-binutils-2.28,1 that does
build.]
I've found one combination that works:
Use of /usr/local/aarch64-freebsd/bin/*
binutils materials mixed with use of
WITHOUT_DEBUG_FILES=
With that it was able to build libc.so.7
and, so, continue wit
[Forcing use of /usr/local/aarch64-freebsd/bin/ld
and other aarch64-binutils-2.28,1 material for the
aarch64 links: that fails too, but with messages
that are more informative (but might be
independent): "R_AARCH64_ABS64 used with TLS
symbol".]
> On 2017-Nov-3, at 9:24 PM, Mark M
On 4/10/17 12:56 am, Ian Lepore wrote:
On Wed, 2017-10-04 at 00:18 +0800, Julian Elischer wrote:
Our 10.4 system is using gcc (for now).
when we compile the devel/binutils port, we get a failure with a
bunch
of these errors:
`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in se
On Wed, 2017-10-04 at 00:18 +0800, Julian Elischer wrote:
> Our 10.4 system is using gcc (for now).
>
> when we compile the devel/binutils port, we get a failure with a
> bunch
> of these errors:
>
>
> `_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in se
Our 10.4 system is using gcc (for now).
when we compile the devel/binutils port, we get a failure with a bunch
of these errors:
`_ZTSN12_GLOBAL__N_110Stub_tableILi64ELb1EEE' referenced in section
`.rodata' of aarch64.o: defined in discarded section
cked off in gcc6-aux's config
> to do a bootstrap.
>
> Even amd64 has build problems (at least for use of the
> modern/experimental ld).
I reverted to an amd64 system based on WITHOUT_LLD_IS_LD= and
that avoided this issue: at least the build has gotten farther
and is still
We've been using the ELF Tool Chain version of tools such as nm,
readelf, size and strings by default for some time. The Binutils
versions can currently be installed instead by setting
WITHOUT_ELFTOOLCHAIN_TOOLS in src.conf(5).
I'm planning to remove the Binutils versions before too
On Wed, Oct 30, 2013 at 11:40:40PM -0400, Eitan Adler wrote:
> On Wed, Oct 30, 2013 at 8:49 PM, Sean Bruno wrote:
> > Spent some time doing string maths today.
> >
> > More or less, change the "static char intel_syntax" to an int and use it
> > as an array index instead of doing pointer math.
> >
On Wed, Oct 30, 2013 at 8:49 PM, Sean Bruno wrote:
> Spent some time doing string maths today.
>
> More or less, change the "static char intel_syntax" to an int and use it
> as an array index instead of doing pointer math.
>
> Sean
>
> http://people.freebsd.org/~sbruno/binutils_opcodes.txt
While
On 10/30/2013 07:49 PM, Sean Bruno wrote:
Spent some time doing string maths today.
More or less, change the "static char intel_syntax" to an int and use it
as an array index instead of doing pointer math.
Sean
http://people.freebsd.org/~sbruno/binutils_opcodes.txt
Looks good to me.
Thanks
Spent some time doing string maths today.
More or less, change the "static char intel_syntax" to an int and use it
as an array index instead of doing pointer math.
Sean
http://people.freebsd.org/~sbruno/binutils_opcodes.txt
signature.asc
Description: This is a digitally signed message part
On Tue, Dec 6, 2011 at 23:41, Andriy Gapon wrote:
> on 06/12/2011 23:24 Martin Matuska said the following:
>> On 6.12.2011 17:48, Andriy Gapon wrote:
>>> Just for your information.
>>> It seems that ld from binutils-2.22 by default has
>>> --no-copy-dt
on 06/12/2011 23:24 Martin Matuska said the following:
> On 6.12.2011 17:48, Andriy Gapon wrote:
>> Just for your information.
>> It seems that ld from binutils-2.22 by default has
>> --no-copy-dt-needed-entries
>> behavior, and so explicit --copy-dt-needed-entr
On 6.12.2011 17:48, Andriy Gapon wrote:
> Just for your information.
> It seems that ld from binutils-2.22 by default has --no-copy-dt-needed-entries
> behavior, and so explicit --copy-dt-needed-entries is now needed where the
> previous default behavior is relied upon.
>
> A
Just for your information.
It seems that ld from binutils-2.22 by default has --no-copy-dt-needed-entries
behavior, and so explicit --copy-dt-needed-entries is now needed where the
previous default behavior is relied upon.
A short excerpt from the man page for your convenience:
> This opt
On 2011-02-22 20:23, Jung-uk Kim wrote:
Since binutils 2.17.50 import, WITH_CTF=1& buildworld on amd64 stops
like this:
...
cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT
-isystem /usr/obj/usr/src/lib32/usr/include/
-L/usr/obj/usr/src/lib32/usr/lib32
-B/usr/obj/usr
Since binutils 2.17.50 import, WITH_CTF=1 & buildworld on amd64 stops
like this:
===> lib/librt (all)
cc -m32 -march=i686 -mmmx -msse -msse2 -mfancy-math-387 -DCOMPAT_32BIT
-isystem /usr/obj/usr/src/lib32/usr/include/
-L/usr/obj/usr/src/lib32/usr/lib32
-B/usr/obj/usr/src/lib32/us
On 2011-02-19 15:35, Dimitry Andric wrote:
Okay, binutils 2.17.50 has now been merged to head in r218822. If you
compile kernels by hand, make sure to first run "make buildworld", or at
least "make kernel-toolchain", to get a new ld in /usr/obj. Otherwise,
linking yo
On 2011-02-16 21:00, Dimitry Andric wrote:
So I plan to merge the binutils-2.17 project branch to head this
weekend, if there are no further objections. If you have found a
showstopper bug, please let me know ASAP. :)
Okay, binutils 2.17.50 has now been merged to head in r218822. If you
On 2011-01-07 21:57, Dimitry Andric wrote:
For some time, I have been working on importing a newer version of
binutils into -current. This updates our quite ancient 2.15 version to
the last version available under GPLv2, 2.17.50.
The binutils 2.17 project branch has been cooking for quite
On Fri, Jan 07, 2011 at 09:57:47PM +0100, Dimitry Andric wrote:
> Hi all,
This is slightly OT. I get this error on ia64 which seems to be
binutils related (still 2.15). I just thought if it is, then it
might have an effect on 2.17 as well.
The error seems to be ia64 specific. On amd64
Erik Cederstrand píše v ne 09. 01. 2011 v 00:10 +0100:
> I was pretty sure I couldn't improve anything with 5 minutes of
> thinking. I'm glad the most obvious things have already been done, and
> I'm sure you and others have put a lot of effort into this. My
> question was more what, if anything,
On Jan 8, 2011, at 3:10 PM, Erik Cederstrand wrote:
> Hello Pav,
>
> Den 08/01/2011 kl. 20.34 skrev Pav Lucistnik:
>
>> Package cluster is quite clever, akshully, and since this is OT here,
>> just terse comments
>
> Sorry, replied to a bad message... redirecting to current@
>
1. adding S
Hello Pav,
Den 08/01/2011 kl. 20.34 skrev Pav Lucistnik:
> Package cluster is quite clever, akshully, and since this is OT here,
> just terse comments
Sorry, replied to a bad message... redirecting to current@
>>> 1. adding SSD disks
>
> irrelevant because of bullet 2.
>
>>> 2. source and des
On 2011-01-08 01:54, Anonymous wrote:
Looks like lang/sbcl doesn't like new ld(1), here on amd64.
Same error when building using devel/binutils. Can you reproduce?
...
//doing warm init - compilation phase
This is SBCL 1.0.43, an implementation of ANSI Common Lisp.
More inform
rent
as of late, especially with long multiprocess builds, such as universes
or bulk packaging with -j nnn. Sometimes it panics. :(
IMO, the best approach would be to make sure it does the right thing
with 'make universe' (twice, naturally, the second time being when all
traces of the p
I'm happy to have a discussion about this topic either publicly, or
privately, your choice. Since your message went to -current@, that's
where my reply is headed. I've also cc'ed ports@ since the topic is
relevant there too.
Meanwhile, I've snipped some of what you wrote to focus on the issues
On Jan 7, 2011, at 9:48 PM, Ade Lovett wrote:
>
> On Jan 07, 2011, at 17:37 , Doug Barton wrote:
>> On 01/07/2011 13:54, Ade Lovett wrote:
>>>
>>> Most likely it's low priority given all the other exp-runs that
>>> affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a
>>> bunch of ot
On Jan 07, 2011, at 17:37 , Doug Barton wrote:
> On 01/07/2011 13:54, Ade Lovett wrote:
>>
>> Most likely it's low priority given all the other exp-runs that
>> affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a
>> bunch of other infrastructure stuff. Not to mention the impending
Dimitry Andric writes:
[...]
> Please report any problems with either the base system, or ports that
> come up as a result of this binutils update.
Looks like lang/sbcl doesn't like new ld(1), here on amd64.
Same error when building using devel/binutils. Can you reproduce
lly deeply care
about system internals being first on the "off the top of my head" list.
But the current system of "don't do anything" just isn't cutting it.
IMO, the best approach would be to make sure it does the right thing
with 'make universe' (t
he best approach would be to make sure it does the right thing with 'make
universe' (twice, naturally, the second time being when all traces of the
previous binutils has been purged from the building system). Once that's done,
commit (please bump __FreeBSD_version as part of this, in
On 01/07/2011 13:29, Dimitry Andric wrote:
On 2011-01-07 22:22, Doug Barton wrote:
This is much appreciated work of course, but I'm wondering if you've
requested an experimental ports run with the change? It would be good to
know how much damage to expect before the change gets committed.
Yes,
On 2011-01-07 22:21, Mehmet Erol Sanliturk wrote:
http://svn.freebsd.org/base/projects/binutils-2.17/
all of the Text files are seen as Binary files by Firefox in Linux
Try http://svn.freebsd.org/viewvc/base/projects/binutils-2.17/ instead.
For checking out the source tree, please use a
On 2011-01-07 22:22, Doug Barton wrote:
This is much appreciated work of course, but I'm wondering if you've
requested an experimental ports run with the change? It would be good to
know how much damage to expect before the change gets committed.
Yes, I submitted an exp-run request Nov 15, 2010
On 01/07/2011 12:57, Dimitry Andric wrote:
Please report any problems with either the base system, or ports that
come up as a result of this binutils update.
This is much appreciated work of course, but I'm wondering if you've
requested an experimental ports run with the change? I
On Fri, Jan 7, 2011 at 3:57 PM, Dimitry Andric wrote:
> Hi all,
>
> For some time, I have been working on importing a newer version of
> binutils into -current. This updates our quite ancient 2.15 version to
> the last version available under GPLv2, 2.17.50. (Special tha
Hi all,
For some time, I have been working on importing a newer version of
binutils into -current. This updates our quite ancient 2.15 version to
the last version available under GPLv2, 2.17.50. (Special thanks to
Nathan Whitehorn for his valuable feedback.)
As far as I know, all issues
. The executable is not marked as being
> >>a FreeBSD executable. It's declared as SYSV, whereas on amd64 it's
> >>properly declared as FreeBSD.
> >>
> >>This is a binutils problem.
> ...
> >Anybody here can explain better what Marcel means
&
s
properly declared as FreeBSD.
This is a binutils problem.
...
Anybody here can explain better what Marcel means
by "binutils problem", and how to fix it?
I've binutils-2.20.1_3 installed from devel/binutils.
The problem is that our base binutils's BFD library has a custo
LSB executable, x86-64, version 1 (FreeBSD), statically
> linked, for FreeBSD 9.0 (900023), not stripped
The branding on ia64 is wrong. The executable is not marked as being
a FreeBSD executable. It's declared as SYSV, whereas on amd64 it's
properly declared as FreeBSD.
Thi
ot defined.
cc -O -pipe -march=pentiumpro -D_GNU_SOURCE -I.
-I/usr/src/gnu/usr.bin/binutils/libbfd/i386
-I/usr/src/gnu/usr.bin/binutils/libbfd
-I/usr/src/gnu/usr.bin/binutils/libbfd/../libbfd/i386
-
I/usr/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/include
-DDEFAULT_VECTOR=bfd_
On Fri, Jun 13, 2003 at 03:42:20PM -0400, Fish wrote:
> Hello list,
>
> I'm sure I've done something naughty as I've been seeing errors for a
> few days, but I've done some troubleshooting and I can't seem to find
> the place I shot myself in the foot.
This is getting a FAQ; I'll add an entry to
tc/make.conf is biting me, only a few things are defined, primarily
CPUTYPE=i686. I usually run at CPUTYPE=p3 (as p4 builds broken code
last I heard) but downgraded here to remove a possible source of error.
CFLAGS and CXXFLAGS are not defined.
cc -O -pipe -march=pentiumpro -D_GNU_SOURCE -I.
-I/usr
^^^I mean,
CCD..
did the buildworld and it has been failed.
==
/usr/src/contrib/binutils/bfd/targets.c -o targets.o
In file included from /usr/src/contrib/binutils/bfd/targets.c:1092:
targmatch.h:7:1: null character(s) ignored
targmatch.h:12:1: null character(s) ignored
On Mon, Jun 09, 2003 at 04:18:46PM -0500, Jeremy Messenger wrote:
> I just CVSup'ed at the phk's lastest committed on UPDATING/CDD stuff. I did
> the buildworld and it has been failed.
>
> ==
> /usr/src/contrib/binutils/bfd/targets.c -o tar
I just CVSup'ed at the phk's lastest committed on UPDATING/CDD stuff. I did
the buildworld and it has been failed.
==
/usr/src/contrib/binutils/bfd/targets.c -o targets.o
In file included from /usr/src/contrib/binutils/bfd/targets.c:1092:
targmatch.h
aware of how it's used; the IUnknown reference was an
analogy; the document you refer to specifically states that it's
to avoid a proliferation of shared library files. That's exactly
the purpose of IUnknown version information for class factories,
as well.
Part of the problem here is t
Loren James Rittle wrote:
> FYI, the libstdc++-v3 maintainers on the FSF side are only
> guaranteeing forward ABI compatibility of any sort if libstdc++.so is
> built with symbol versioning and symbol hiding.
FWIW: symbol versioning is incredibly broken. It attempts to
do in UNIX what interface v
Doug Rabson wrote:
> In the windows world, all this is handled by having a strict list of explicit
> symbol exports, either in the source code using syntax extensions or with a
> file supplied to the linker. I'm not sure whether binutils supports this kind
> of thing but it
Fixed a few minutes ago.
On Thu, Jul 04, 2002 at 02:12:39AM -0400, Munish Chopra wrote:
> Sources checked out today, 3AM EST.
>
> makeinfo --no-validate -I
> /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/gas/doc
> -I /usr/src/gnu/usr.bin/binutils/doc/../.
Sources checked out today, 3AM EST.
makeinfo --no-validate -I
/usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/gas/doc
-I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/ld -I
/usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binutils/bfd/doc
-I
/usr/src/gnu
On Sat, 22 Jun 2002, David O'Brien wrote:
> On Sat, Jun 22, 2002 at 09:59:44AM -0700, Steve Kargl wrote:
> > make: don't know how to make remote.texi. Stop
> > remote.texi does not exist in /usr/src.
> >
> > The obvious fix of removing remote.texi from the Makefile
> > doesn't work because of
>
>
On Sat, Jun 22, 2002 at 10:05:38AM -0700, David O'Brien wrote:
> On Sat, Jun 22, 2002 at 09:59:44AM -0700, Steve Kargl wrote:
> > make: don't know how to make remote.texi. Stop
> > remote.texi does not exist in /usr/src.
> >
> > The obvious fix of removing remote.texi from the Makefile
> > doesn'
On Sat, Jun 22, 2002 at 09:59:44AM -0700, Steve Kargl wrote:
> make: don't know how to make remote.texi. Stop
> remote.texi does not exist in /usr/src.
>
> The obvious fix of removing remote.texi from the Makefile
> doesn't work because of
I just took a larger hammer and just turned off docs.
T
sp.info > gasp.info.gz
ln -sf /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/gdb/gdb/doc/\
all-cfg.texi gdb-cfg.texi
make: don't know how to make remote.texi. Stop
remote.texi does not exist in /usr/src.
The obvious fix of removing remote.texi from the Makefile
doesn't wo
This looks like a causality of David's removal of gdb.291.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
makeinfo --no-validate -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/
binutils/gas/doc -I /usr/src/gnu/usr.bin/binutils/doc/../../../../contrib/binuti
ls/ld -I /us
--- David Wolfskill <[EMAIL PROTECTED]> wrote:
> I'm not obrien, but yes, that is exactly what it means.
Hmm, but I haven't defined it anywhere, and trust me on that, as I
cvsup'ed a clean copy of the 'src' tree today, an deleting the old one.
__
D
> Please verify my hypothesis by applying this patch:
>
>
> Index: contrib/binutils/bfd/sysdep.h
> ===
> RCS file: /home/ncvs/src/contrib/binutils/bfd/sysdep.h,v
> retrieving revision 1.1.1.6
> di
>
> I also looked at all the Makefiles, but couldn't find a problem related
> to this. Out of curiosity, could it be because of a kernel option(s)
> which I am using?
Nope.
Please verify my hypothesis by applying this
Hi,
I am attaching the output you requested, but I am sure, this wouldn't
be very helpful though:
/usr/bin/cc (which cc)
Using builtin specs.
gcc version 2.95.3 20010315 (release) (cc -v)
I also looked at all the Makefiles, but couldn't find a problem related
to this. Out of curiosity, could
rfectly, but I am getting this problem
> for some reason which I can't seem to figure out. Also, I downloaded a
> clean copy of the binutils tree, but I am still having the same problem.
>
> I tried this:
>
> #cd /usr/src/contrib
> #rm -rf binutils
> #cd /usr/src/supfile
Also, I downloaded a
clean copy of the binutils tree, but I am still having the same problem.
I tried this:
#cd /usr/src/contrib
#rm -rf binutils
#cd /usr/src/supfiles
#cvsup -L2 -g srcsup
U binutils/...
..
..
But still.. the same problem occurs to me. Shall I try with the copy from
http://ww
On Fri, Mar 08, 2002 at 05:56:08PM +, Hiten Pandya wrote:
>
>/data/dev/src/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/sysdep.h:135:
> libintl.h: No such file or directory
This only happens if ENABLE_NLS is defined. However,
$ cd /usr/src/gnu/usr.bin
On Fri, Mar 08, 2002 at 01:06:41PM -0500, Michael Lucas wrote:
> pedicular~;locate libintl.h
> /usr/local/include/libintl.h
> /usr/src/contrib/texinfo/lib/libintl.h
> pedicular~;pkg_info -W /usr/local/include/libintl.h
> /usr/local/include/libintl.h was installed by package gettext-0.10.35_1
> pe
--- Michael Lucas <[EMAIL PROTECTED]> wrote:
> pedicular~;locate libintl.h
> /usr/local/include/libintl.h
> /usr/src/contrib/texinfo/lib/libintl.h
> pedicular~;pkg_info -W /usr/local/include/libintl.h
> /usr/local/include/libintl.h was installed by package gettext-0.10.35_1
> pedicular~;
Thanks!
Pandya wrote:
>
> Hi all,
>
> I am getting this weird binutils error, which says, that I am lacking a
> file called . I checked my /usr/include, and
> /usr/src/include. Also, I checked the src/contrib/binutils directory,
> but I cannot find that particular header file at all.
Hi all,
I am getting this weird binutils error, which says, that I am lacking a
file called . I checked my /usr/include, and
/usr/src/include. Also, I checked the src/contrib/binutils directory,
but I cannot find that particular header file at all.
I have the most updated source, as of Fri
Hi, I recently rebuilt Mozilla and kdebase on my (very up to date) current box. Since
then, both moz and most KDE apps have been very crashy. I think this is probably
something to do with binutils, but is there any way I can check? and are there any
workarounds?
Additional info: x86 machine
es anyone know if the problem with kde and other programs not
> > > > working with the new binutils not working have been fixed yet?
> > >
> > > I find that mozilla 0.9.8 dies with pure virtual called or something
> > > to that effect, however I don't
Never mind. My bad.
--
Michael D. Harnois bilocational bivocational
Pastor, Redeemer Lutheran ChurchWashburn, Iowa
1L, UST School of Law Minneapolis, Minnesota
The price one pays for pursuing any profession, or calling,
is an intimate knowle
> first time only:
>
>cd /usr/src/gnu/usr.bin/binutils
>cvs -qR up -D '1/27/2002 11:55 UTC'
>cd /usr/src/contrib/binutils
>cvs -qR up -D '1/27/2002 11:55 UTC'
I thought this sounded like a great idea, but it gives me
In file included from
I read recently on this list that the problem with the
-current binutils on Alphas had been fixed, did this also
fix the problem on i386 which caused ports such as imlib,
imlib2 and gnomelibs to behave weirdly as many of their
binaries would segfault during
configuring/linking/executing? I
Does anyone know if the problem with kde and other programs not
working with the new binutils not working have been fixed yet?
--
David W. Chapman Jr.
[EMAIL PROTECTED] Raintree Network Services, Inc.
[EMAIL PROTECTED] FreeBSD Committer
To Unsubscribe: send mail to [EMAIL PROTECTED
Never mind. My bad.
--
Michael D. Harnois bilocational bivocational
Pastor, Redeemer Lutheran ChurchWashburn, Iowa
1L, UST School of Law Minneapolis, Minnesota
The price one pays for pursuing any profession, or calling,
is an intimate knowle
> first time only:
>
>cd /usr/src/gnu/usr.bin/binutils
>cvs -qR up -D '1/27/2002 11:55 UTC'
>cd /usr/src/contrib/binutils
>cvs -qR up -D '1/27/2002 11:55 UTC'
I thought this sounded like a great idea, but it gives me
In file included from
es anyone know if the problem with kde and other programs not
> > > > working with the new binutils not working have been fixed yet?
> > >
> > > I find that mozilla 0.9.8 dies with pure virtual called or something
> > > to that effect, however I don't
Alfred Perlstein wrote:
> I think what happens is people like me sometimes just install a new
> package over the old instead of properly deinstalling first. I think
> what's actually happening is that files from 0.9.6 are getting picked
> up by 0.9.8 because 0.9.7 spammed 0.9.6's plist.
That sho
* Terry Lambert <[EMAIL PROTECTED]> [020208 07:12] wrote:
> Alfred Perlstein wrote:
> > If you do a pkg_deletew of mozilla and then nuke /usr/X11R6/lib/mozilla
> > then reinstall it the problem should go away.
>
> pgk_deelete is broken?!?
I think what happens is people like me sometimes just ins
1 - 100 of 222 matches
Mail list logo
