[Bug gas/10549] gas doesn't provide correct ELF ABI for object with unique symbols
http://sourceware.org/bugzilla/show_bug.cgi?id=10549 --- Comment #4 from cvs-commit at gcc dot gnu.org 2011-04-11 08:13:26 UTC --- CVSROOT:/cvs/src Module name:src Changes by:ni...@sourceware.org2011-04-11 08:13:22 Modified files: bfd: ChangeLog elf-bfd.h elf.c elf32-arm.c elf32-i386.c elf32-ppc.c elf32-sparc.c elf64-ppc.c elf64-sparc.c elf64-x86-64.c ld/testsuite : ChangeLog Added files: ld/testsuite/ld-unique: unique.exp unique.s unique_empty.s unique_shared.s Log message: PR 10549 * elf-bfd.h (has_ifunc_symbols): Renamed to has_gnu_symbols. (has_gnu_symbols): Renamed from has_ifunc_symbols. * elf.c (_bfd_elf_set_osabi): Use new has_gnu_symbols name. * elf32-arm.c (elf32_arm_add_symbol_hook): Set has_gnu_symbols also if STB_GNU_UNIQUE symbol binding was seen. * elf32-i386.c (elf_i386_add_symbol_hook): Likewise. * elf32-ppc.c (ppc_elf_add_symbol_hook): Likewise. * elf32-sparc.c (elf32_sparc_add_symbol_hook): Likewise. * elf64-ppc.c (ppc64_elf_add_symbol_hook): Likewise. * elf64-sparc.c (elf64_sparc_add_symbol_hook): Likewise. * elf64-x86-64.c (elf_x86_64_add_symbol_hook): Likewise. * ld-unique: New directory. * ld-unique/unique.exp: New file: Run the UNIQUE tests. * ld-unique/unique.s: New test file. * ld-unique/unique_empty.s: Likewise. * ld-unique/unique_shared.s: Likewise. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/ChangeLog.diff?cvsroot=src&r1=1.5300&r2=1.5301 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf-bfd.h.diff?cvsroot=src&r1=1.315&r2=1.316 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf.c.diff?cvsroot=src&r1=1.530&r2=1.531 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf32-arm.c.diff?cvsroot=src&r1=1.262&r2=1.263 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf32-i386.c.diff?cvsroot=src&r1=1.246&r2=1.247 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf32-ppc.c.diff?cvsroot=src&r1=1.292&r2=1.293 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf32-sparc.c.diff?cvsroot=src&r1=1.94&r2=1.95 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf64-ppc.c.diff?cvsroot=src&r1=1.346&r2=1.347 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf64-sparc.c.diff?cvsroot=src&r1=1.125&r2=1.126 http://sourceware.org/cgi-bin/cvsweb.cgi/src/bfd/elf64-x86-64.c.diff?cvsroot=src&r1=1.219&r2=1.220 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ChangeLog.diff?cvsroot=src&r1=1.1384&r2=1.1385 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-unique/unique.exp.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-unique/unique.s.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-unique/unique_empty.s.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/testsuite/ld-unique/unique_shared.s.diff?cvsroot=src&r1=NONE&r2=1.1 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Problem with 2.21 ld when linking HelenOS ia64 binaries
Hi Jakub, The following instruction: addl r36 = @ltoff(@fptr(__entry#)), gp gets linked as either (ld 2.20): 28806: 40 02 04 00 48 20 addl r36=0,r1 or (ld 2.21): 24846: 40 02 07 8c 48 20 addl r36=9056,r1 Have you verified that the object files produced by the 2.20 and 2.21 assemblers are the same ? (Including the relocs). If not then this could be a gas bug rather than an ld bug... I would be grateful for any hint that would explain the sudden runaway gp offset. It sounds like the evaluation of the relocation that computes the gp offset is going wrong. Without more context it is hard to theorize any further. Things that you could try include: * Submit a bug report to http://sourceware.org/bugzilla/ If you include a small testcase to reproduce the problem that would really help. * Try a binary chop search to find out which patch caused the problem. This assumes that you have a lot of bandwidth and/or a local copy of the binutils CVS archive... * Look at the source code in bfd/elfxx-ia64.c and see if you can find the problem. As a first guess I would suggest looking at how the LTOFF_FPTR22, LTOFF_FPTR64I, LTOFF_FPTR32MSB, LTOFF_FPTR32LSB, LTOFF_FPTR64MSB and LTOFF_FPTR64LSB relocations are processed in the ...check_relocs() and ...relocate_section() functions. Cheers Nick ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12658] ld: potential infinite loop and memory leaks when link many object files
http://sourceware.org/bugzilla/show_bug.cgi?id=12658 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #2 from Nick Clifton 2011-04-11 11:56:07 UTC --- Hi Dongsheng, Have you tried linking with the --reduce-memory-overheads option specified ? It is entirely possible that there are memory leaks in the linker, but without a lot of analysis it is hard to say where they might be. It does sound as though you are producing a really big DLL, so maybe it is just a case that you need lots of memory to perform the link. Have you tried using earlier versions of the linker to see if this problem is something that has only recently been introduced ? Cheers Nick -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12662] New: Unable to link with shared object (without lib prefix) or in different path
http://sourceware.org/bugzilla/show_bug.cgi?id=12662 Summary: Unable to link with shared object (without lib prefix) or in different path Product: binutils Version: 2.17 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sources.redhat.com ReportedBy: tarunactiv...@yahoo.com I am using RHEL 5 on z/OS . 2.6.18-128.el5 #1 SMP Wed Dec 17 11:45:02 EST 2008 s390x s390x s390x GNU/Linux GNU ld version 2.17.50.0.6-9.el5 20061020 I need to link with shared object files not having the lib prefix, that are added to the LD_LIBRARY_PATH . I am trying to achieve the following while linking: 1. Use shared object libraries not having the lib-prefix in the name. 2. Use libraries listed in different path ( present in LD_LIBRARY_PATH ) 3. Final output should be able to pickup the library from the LD_LIBRARY_PATH Solution 1: Link using the full path to library, This works even with non standard naming i.e. without the lib prefix , however, the link is hard coded in the exe. ( This can be confirmed from ldd exename ) , which works only when the libraries are in the same path. /usr/bin/g++ -v -o /tmp/conserv ./conserv.o /path/to/.so /path/to/.so /path/to/.so -lpthread -L/usr/lib64 -lc -lncurses -ldl Solution 2: Link with the shared-object in the current folder Here, the exe will look for the library in the same folder. We need the libraries to be picked up from the LIBPATH/LD_LIBRARY_PATH /usr/bin/g++ -v -o /tmp/conserv ./conserv.o .so .so .so -lpthread -L/usr/lib64 -lc -lncurses -ldl Solution 3: Rename libraries to "lib" form Here, the linker will pick up the libs as specifid by -l ( where lib is the shared object name ), and the path is specified in LIBPATH/LD_LIBRARY_PATH rename Libs to lib* /usr/bin/g++ -v -o /tmp/conserv ./conserv.o -l -l -l -lpthread -L/usr/lib64 -lc -lncurses -ldl However, this works only if the libs are renamed as lib.so . The macro -l: does not seem to work with the non standard naming of shared objects. http://stackoverflow.com/questions/207069/how-to-link-using-gcc-without-l-and-without-hardcoding-path Is this version specific? How do we link with shared objects, without the lib-prefix , and without having the shared-object in the same path? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
Re: Problem with 2.21 ld when linking HelenOS ia64 binaries
Hi Nick, Quoting Nick Clifton : The following instruction: addl r36 = @ltoff(@fptr(__entry#)), gp gets linked as either (ld 2.20): 28806: 40 02 04 00 48 20 addl r36=0,r1 or (ld 2.21): 24846: 40 02 07 8c 48 20 addl r36=9056,r1 Have you verified that the object files produced by the 2.20 and 2.21 assemblers are the same ? (Including the relocs). If not then this could be a gas bug rather than an ld bug... No actually. What I did was that I built with 2.21 assembler (and 4.6 gcc) and obtained a set of .o files. When I start the linking phase from the these .o files, I get two different results depending on ld version. (Please ignore the program counter addresses as I unfortunately copy-n-pasted older disassembly where the instruction was located at different address. This does not change anything about the above observation though.) It sounds like the evaluation of the relocation that computes the gp offset is going wrong. Without more context it is hard to theorize any further. Things that you could try include: * Submit a bug report to http://sourceware.org/bugzilla/ If you include a small testcase to reproduce the problem that would really help. In the worst case, I could attach my .o files, the linker script and the linker command line. I will try to see if I can limit the test case to only one .o. Thanks, Jakub This message was sent using IMP, the Internet Messaging Program. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12658] ld: potential infinite loop and memory leaks when link many object files
http://sourceware.org/bugzilla/show_bug.cgi?id=12658 --- Comment #3 from Dongsheng Song 2011-04-11 13:21:36 UTC --- (In reply to comment #2) > Hi Dongsheng, > > Have you tried linking with the --reduce-memory-overheads option specified ? > > It is entirely possible that there are memory leaks in the linker, but > without a lot of analysis it is hard to say where they might be. > > It does sound as though you are producing a really big DLL, so maybe it is > just a case that you need lots of memory to perform the link. Have you tried > using earlier versions of the linker to see if this problem is something that > has only recently been introduced ? > > Cheers > Nick When I use '-Wl,--no-keep-memory,--reduce-memory-overheads', only reduce about 200MB memory usage. I'm not very care about the memory usage, I'm more concern the infinite loop during link because it blocked from generate the final .DLL file. *) 25 minutes Cpu(s): 16.2%us, 8.0%sy, 0.0%ni, 75.0%id, 0.0%wa, 0.0%hi, 0.7%si, 0.0%st Mem: 3095296k total, 3073056k used,22240k free, 32k buffers Swap: 7811064k total,0k used, 7811064k free, 321800k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 1159 dongshen 20 0 2627m 2.6g 896 R 104 86.7 25:35.69 ld -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12658] ld: potential infinite loop and memory leaks when link many object files
http://sourceware.org/bugzilla/show_bug.cgi?id=12658 Nick Clifton changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Nick Clifton 2011-04-11 13:58:12 UTC --- Hi Dongsheg, Ok - we are going to need a testcase that reproduced this problem then. I appreciate that this might be difficult as I assume that you will not be able to reduce the size/number of object files involved. If you can place a compressed tarball somewhere where I can download it and give me a full linker command line, I will try reproducing the problem myself. Cheers Nick -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/12296] cortex-m3: SVC is not permitted on this architecture
http://sourceware.org/bugzilla/show_bug.cgi?id=12296 --- Comment #5 from cvs-commit at gcc dot gnu.org 2011-04-11 15:23:12 UTC --- CVSROOT:/cvs/src Module name:src Changes by:ni...@sourceware.org2011-04-11 15:23:09 Modified files: gas/testsuite : ChangeLog gas/testsuite/gas/arm: arch7.d arch7.s attr-march-armv7.d include/opcode : ChangeLog arm.h Log message: PR gas/12296 * arm.h (ARM_AEXT_V7_ARM): Add ARM_EXT_OS. * gas/arm/arch7.s: Add SVC insn. * gas/arm/arch7.d: Add disassembly of SVC insn. * gas/arm/attr-march-armv7.d: Add arch profile tag. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/testsuite/ChangeLog.diff?cvsroot=src&r1=1.1879&r2=1.1880 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/arch7.d.diff?cvsroot=src&r1=1.6&r2=1.7 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/arch7.s.diff?cvsroot=src&r1=1.2&r2=1.3 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gas/testsuite/gas/arm/attr-march-armv7.d.diff?cvsroot=src&r1=1.3&r2=1.4 http://sourceware.org/cgi-bin/cvsweb.cgi/src/include/opcode/ChangeLog.diff?cvsroot=src&r1=1.435&r2=1.436 http://sourceware.org/cgi-bin/cvsweb.cgi/src/include/opcode/arm.h.diff?cvsroot=src&r1=1.24&r2=1.25 -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/12296] cortex-m3: SVC is not permitted on this architecture
http://sourceware.org/bugzilla/show_bug.cgi?id=12296 --- Comment #6 from Matthew.Gretton-Dann at arm dot com 2011-04-11 15:24:00 UTC --- Hi, I am out of the office until Monday 18th April 2011, and will not be reading email. If you have an urgent issue please get in touch with Richard Earnshaw. Otherwise, I will get back to you as soon as possible after I am back in the office on Monday 18th April 2011. Thanks, Matt -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/12296] cortex-m3: SVC is not permitted on this architecture
http://sourceware.org/bugzilla/show_bug.cgi?id=12296 --- Comment #7 from Nick Clifton 2011-04-11 15:24:41 UTC --- Hi Dan, Thanks very much for revised patch. I have now checked it in along with these changelog entries. Cheers Nick include/opcode/ChangeLog 2011-04-11 Dan McDonald PR gas/12296 * arm.h (ARM_AEXT_V7_ARM): Add ARM_EXT_OS. gas/testsuite/ChangeLog 2011-04-11 Dan McDonald PR gas/12296 * gas/arm/arch7.s: Add SVC insn. * gas/arm/arch7.d: Add disassembly of SVC insn. * gas/arm/attr-march-armv7.d: Add arch profile tag. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/12296] cortex-m3: SVC is not permitted on this architecture
http://sourceware.org/bugzilla/show_bug.cgi?id=12296 Nick Clifton changed: What|Removed |Added Status|NEW |RESOLVED CC||nickc at redhat dot com Resolution||FIXED --- Comment #8 from Nick Clifton 2011-04-11 15:25:17 UTC --- patch applied -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12658] ld: potential infinite loop and memory leaks when link many object files
http://sourceware.org/bugzilla/show_bug.cgi?id=12658 --- Comment #5 from Dongsheng Song 2011-04-11 15:36:47 UTC --- Created attachment 5661 --> http://sourceware.org/bugzilla/attachment.cgi?id=5661 Compile gcc 4.6 for mingw-w64 target -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12534] arm: disassembly of pc-relative ldrd instructions not fully annotated in Thumb
http://sourceware.org/bugzilla/show_bug.cgi?id=12534 Nick Clifton changed: What|Removed |Added Status|NEW |WAITING CC||nickc at redhat dot com --- Comment #1 from Nick Clifton 2011-04-11 15:52:15 UTC --- Hi Dave, I believe that this problem is fixed now. Please could you check locally and confirm ? Cheers Nick -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12658] ld: potential infinite loop and memory leaks when link many object files
http://sourceware.org/bugzilla/show_bug.cgi?id=12658
--- Comment #6 from Dongsheng Song 2011-04-11
15:37:39 UTC ---
(In reply to comment #5)
> Created attachment 5661 [details]
> Compile gcc 4.6 for mingw-w64 target
Sorry, the working directory size is 1.2GB, it's too hard to upload.
Maybe you can build yourself:
1) build mingw-w64 cross compiler
If you use Debian 6.0 i686 or amd64 box, I can upload the compiler.
See gcc-4.6-windows-x86.sh for more details.
2) Checkout wxWidgets 2.8 branch
(http://svn.wxwidgets.org/svn/wx/wxWidgets/branches/WX_2_8_BRANCH)
3) Configure
CFLAGS='-pipe' CXXFLAGS='-pipe' LDFLAGS='-pipe -s -static' \
${HOME}/vcs/svn/wxWidgets/branches/WX_2_8_BRANCH/configure --prefix=/tmp/w32
--host=i686-w64-mingw32 \
--with-odbc --with-opengl --enable-shared --enable-unicode --enable-mediactrl
--enable-official_build --disable-compat26 --enable-abi-incompatible-features
...
Configured wxWidgets 2.8.12 for `i686-w64-mingw32'
Which GUI toolkit should wxWidgets use? msw
Should wxWidgets be compiled into single library? no
Should wxWidgets be compiled in debug mode? no
Should wxWidgets be linked as a shared library? yes
Should wxWidgets be compiled in Unicode mode? yes
What level of wxWidgets compatibility should be enabled?
wxWidgets 2.4 no
wxWidgets 2.6 no
Which libraries should wxWidgets use?
jpeg builtin
pngbuiltin
regex builtin
tiff builtin
zlib builtin
odbc yes
expat builtin
libmspack no
sdlno
4) build
make -j2
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12664] New: ld bug ?
http://sourceware.org/bugzilla/show_bug.cgi?id=12664 Summary: ld bug ? Product: binutils Version: 2.21 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassig...@sources.redhat.com ReportedBy: ralpheng...@gmail.com first time here so bear with me. im encountering some trouble bootstrapping gcc-4.6.0 on mingw64, unfortunatly the error is a bit obscure. see below. collect2: ld returned 116 exit status make[3]: *** [lto1.exe] Error 1 make[3]: *** Waiting for unfinished jobs collect2: ld returned 116 exit status make[3]: *** [cc1.exe] Error 1 rm gcc.pod make[3]: Leaving directory `/e/sources/build64/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/e/sources/build64' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/e/sources/build64' make: *** [all] Error 2 error allways happens in stage 1 bootstrap when building the 64 bit version of gcc. the real weird one is that the 32 bit bootstrap of gcc works fine. binutils 2.20 works it seems, but only with an older version of gcc to bootstrap gcc-4.6.0. what im not sure about is it a bug in binutils on windows or a gcc bug ?. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/12532] arm: gas may assemble b to locally-defined, preemptible global symbol as "b.n"
http://sourceware.org/bugzilla/show_bug.cgi?id=12532 --- Comment #2 from Nick Clifton 2011-04-11 16:18:01 UTC --- Created attachment 5662 --> http://sourceware.org/bugzilla/attachment.cgi?id=5662 Do not relax relocations to preemptable global symbols -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/12532] arm: gas may assemble b to locally-defined, preemptible global symbol as "b.n"
http://sourceware.org/bugzilla/show_bug.cgi?id=12532 Nick Clifton changed: What|Removed |Added Status|NEW |WAITING CC||nickc at redhat dot com --- Comment #3 from Nick Clifton 2011-04-11 16:19:38 UTC --- Hi Dave, I think that we should be supporting the possibility of symbol preemption. So please could you try out the uploaded patch and let me know if it resolves the problem for you. Cheers Nick PS. Hmm, I wonder if we should support a command line feature to enable/disable this behaviour, and what the default setting should be... -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12662] Unable to link with shared object (without lib prefix) or in different path
http://sourceware.org/bugzilla/show_bug.cgi?id=12662 Alan Modra changed: What|Removed |Added Status|NEW |RESOLVED CC||amodra at gmail dot com Resolution||WORKSFORME --- Comment #1 from Alan Modra 2011-04-12 05:06:10 UTC --- Build your shared libraries with a soname. See the ld info docs. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12662] Unable to link with shared object (without lib prefix) or in different path
http://sourceware.org/bugzilla/show_bug.cgi?id=12662 TTA changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | Ever Confirmed|1 |0 --- Comment #2 from TTA 2011-04-12 05:19:31 UTC --- (In reply to comment #1) > Build your shared libraries with a soname. See the ld info docs. I assume you mean to build .so , .so with : -h FILENAME, -soname FILENAME How would this help / Does this change the linking process? -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/12662] Unable to link with shared object (without lib prefix) or in different path
http://sourceware.org/bugzilla/show_bug.cgi?id=12662 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Alan Modra 2011-04-12 06:12:22 UTC --- Replied privately. Please do not reopen this bug report. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12665] New: configure in binutils-2.21 does not correctly handle CLooG 0.16.2
http://sourceware.org/bugzilla/show_bug.cgi?id=12665
Summary: configure in binutils-2.21 does not correctly handle
CLooG 0.16.2
Product: binutils
Version: 2.21
Status: NEW
Severity: normal
Priority: P2
Component: binutils
AssignedTo: unassig...@sources.redhat.com
ReportedBy: y-i...@secom.co.jp
With CLooG 0.16.2, the configure script comes with binutils-2.21 prints:
checking for version 0.15.5 (or later revision) of CLooG
but, it barfs "no".
config.log reads:
-BEGIN-
configure:5770: gcc -c -g -O2 -I/opt/gnu/include -DCLOOG_PPL_BACKEND
-DCLOOG_INT_GMP conftest.c >&5
conftest.c: In function 'main':
conftest.c:16:3: error: unknown type name 'choke'
configure:5770: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define LT_OBJDIR ".libs/"
| /* end confdefs.h. */
| #include "cloog/cloog.h"
| int
| main ()
| {
|
| #if CLOOG_VERSION_MAJOR != 0 || CLOOG_VERSION_MINOR != 15 ||
CLOOG_VERSION_REVISION < 5
| choke me
-END-
CLOOG_VERSION_MINOR is compared by "not equal", but it should be compared by
"less or equal".
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
bug-binutils mailing list
bug-binutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/12665] configure in binutils-2.21 does not correctly handle CLooG 0.16.2
http://sourceware.org/bugzilla/show_bug.cgi?id=12665 --- Comment #1 from IIDA Yosiaki 2011-04-12 06:43:38 UTC --- I wrote that it should be compared by "less or equal", but precisely: ((CLOOG_VERSION_MAJOR < 0) || (CLOOG_VERSION_MAJOR == 0 && CLOOG_VERSION_MINOR < 15) || (CLOOG_VERSION_MAJOR == 0 && CLOOG_VERSION_MINOR == 15 && CLOOG_VERSION_REVISION < 5)) Oops. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
