Re: [Openocd-development] RPM Build
Just to make everything clear, I did a build with the shared library for OpenOCD. This is the result on the final binary using ldd: $ ldd /usr/bin/openocd linux-vdso.so.1 = (0x7fffed7ff000) libopenocd.so.0 = /usr/lib64/libopenocd.so.0 (0x7fce2f631000) libdl.so.2 = /lib64/libdl.so.2 (0x00371b40) libftdi.so.1 = /usr/lib64/libftdi.so.1 (0x00316180) libusb-0.1.so.4 = /usr/lib64/libusb-0.1.so.4 (0x00372e20) libc.so.6 = /lib64/libc.so.6 (0x00371ac0) /lib64/ld-linux-x86-64.so.2 (0x00371a80) $ So I guess either the static library build should be used and the resulting libopenocd.a needs to be deleted or the shared object is just shipped with the RPM. There can be a development package later once the interface is finalized for the library that includes the link to the unversioned so and the needed header files. These are not part of this package so people shouldn't be able to work with the library without some work on their part. // Dean Glazeski On Wed, Aug 19, 2009 at 2:00 PM, Dean Glazeski dngl...@gmail.com wrote: Well, the problem is that the default is to actually build a static library. If you try to disable the static library without enabling the shared library, it will still make the static library anyway. I think it's a problem with the build, but I don't know how to work with the autoconf/automake chain. // Dean Glazeski David Brownell wrote: On Tuesday 18 August 2009, Dean Glazeski wrote: I can't disable the building of libraries so I assumed the library was in use by the OpenOCD executable. Am I mistaken? On this system: $ ldd src/openocd linux-vdso.so.1 = (0x7fff7dbfe000) libdl.so.2 = /lib/libdl.so.2 (0x7fbb7561a000) libftdi.so.1 = /usr/local/lib/libftdi.so.1 (0x7fbb75414000) libusb-0.1.so.4 = /lib/libusb-0.1.so.4 (0x7fbb7520c000) libc.so.6 = /lib/libc.so.6 (0x7fbb74eaa000) /lib64/ld-linux-x86-64.so.2 (0x7fbb7581e000) $ With that /usr/local/... stuff working around Ubuntu 8.04 version issues with those libraries (configure CFLAGS=... LDFLAGS=...) If so, I can just have the spec file delete the libraries that the make process creates. If there is a configuration option I need to use to make the final server not use an external library, let me know what it is. Thanks. I use configure ... --disable-shared ... which IMO ought to be the default. - Dave // Dean Glazeski David Brownell wrote: On Thursday 06 August 2009, Chitlesh GOORAH wrote: Keep an eye on https://bugzilla.redhat.com/show_bug.cgi?id=502130 for further updates. You should not include a libopenocd ... there are are *NO* public supported programming interfaces in that code. Don't include any library at all; just openocd server that links against stuff like libftdi and libusb. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
On Friday 21 August 2009, Dean Glazeski wrote: So I guess either the static library build should be used and the resulting libopenocd.a needs to be deleted Yes. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Well, the problem is that the default is to actually build a static library. If you try to disable the static library without enabling the shared library, it will still make the static library anyway. I think it's a problem with the build, but I don't know how to work with the autoconf/automake chain. // Dean Glazeski David Brownell wrote: On Tuesday 18 August 2009, Dean Glazeski wrote: I can't disable the building of libraries so I assumed the library was in use by the OpenOCD executable. Am I mistaken? On this system: $ ldd src/openocd linux-vdso.so.1 = (0x7fff7dbfe000) libdl.so.2 = /lib/libdl.so.2 (0x7fbb7561a000) libftdi.so.1 = /usr/local/lib/libftdi.so.1 (0x7fbb75414000) libusb-0.1.so.4 = /lib/libusb-0.1.so.4 (0x7fbb7520c000) libc.so.6 = /lib/libc.so.6 (0x7fbb74eaa000) /lib64/ld-linux-x86-64.so.2 (0x7fbb7581e000) $ With that /usr/local/... stuff working around Ubuntu 8.04 version issues with those libraries (configure CFLAGS=... LDFLAGS=...) If so, I can just have the spec file delete the libraries that the make process creates. If there is a configuration option I need to use to make the final server not use an external library, let me know what it is. Thanks. I use configure ... --disable-shared ... which IMO ought to be the default. - Dave // Dean Glazeski David Brownell wrote: On Thursday 06 August 2009, Chitlesh GOORAH wrote: Keep an eye on https://bugzilla.redhat.com/show_bug.cgi?id=502130 for further updates. You should not include a libopenocd ... there are are *NO* public supported programming interfaces in that code. Don't include any library at all; just openocd server that links against stuff like libftdi and libusb. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
I can't disable the building of libraries so I assumed the library was in use by the OpenOCD executable. Am I mistaken? If so, I can just have the spec file delete the libraries that the make process creates. If there is a configuration option I need to use to make the final server not use an external library, let me know what it is. Thanks. // Dean Glazeski David Brownell wrote: On Thursday 06 August 2009, Chitlesh GOORAH wrote: Keep an eye on https://bugzilla.redhat.com/show_bug.cgi?id=502130 for further updates. You should not include a libopenocd ... there are are *NO* public supported programming interfaces in that code. Don't include any library at all; just openocd server that links against stuff like libftdi and libusb. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Dean Glazeski wrote: What's interesting is that it appears that just about everything that goes into /usr/libqual is probably better suited in /usr/share. This is from a 0.1.0 perspective, but all of the TCL scripts, config scripts, and the pre-built elf (for ecos) and bin (for xscale) are all host architecture independent and should be in /usr/share. Agreed. The config scripts, however, might have a better place in /etc/openocd or some such since they configure the operation of OpenOCD. I think this may affect some of the pieces that are looking for these TCL scripts and the config scripts, but I haven't looked into that stuff. I think these also belong in /usr/share - after all, the user should use them as-is and should not need to edit them. A global openocd config file might belong in /etc, but AFAIK, there is no such thing currently, and given the nature of openocd, I doubt there will be much use for a config file with global settings - at least I need 2-3 different settings depending on what target I am working on. cu Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] RPM Build
Hey all, Can anyone give me insight on these files: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: E: missing-PT_GNU_STACK-section /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/example.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.h openocd.x86_64: W: file-not-utf8 /usr/share/info/openocd.info.gz I need to know what they are for so I can take the appropriate action to fix them for the RPM build for Fedora. I know the last one is the info file. I'm going to look into making a match that makes it UTF to make things happy. I'm not sure what the other files are for. Do they make sense in a final distribution of OpenOCD? If so, what are they for? I appreciate any help I can get. Thanks. // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Magnus Lundin wrote: Dean Glazeski wrote: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: E: missing-PT_GNU_STACK-section /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/example.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.h openocd.x86_64: W: file-not-utf8 /usr/share/info/openocd.info.gz I think : The libddc files are for building target dcc implementations, and nothing in this list is used by the actual running openocd image on fedora. So this is really reference materials for developers. That might help you decide where to place them. Does this mean I can just remove them and be happy? Doing that definitely makes my life much simpler ;). Unless I hear otherwise, I'll rebuild the RPM without these later tonight (its 7pm where I'm at) and I'll throw the RPM up for review with Fedora tomorrow. Thanks! // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Dean Glazeski wrote: Hey all, Can anyone give me insight on these files: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf /usr/lib64/openocd/ecos/at91eb40a.elf These are *TARGET* files, the package tool you have is *WRONG*HEADED*, or mis-informed - it sees the file as an ELF, then wrong assumes it is an *ELF* target for the intended HOST. You might want to ask the packaging people how to identify such files My hunch is, they have *NEVER* thought about this situation! openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/example.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.h Again, I think the package tool is wrong or mis-informed, this is a cross compilation package - these are example source files that a user of this tool might use - they are not *HOST* files, but are instead, *TARGET* files and are rightfully included in the package. openocd.x86_64: W: file-not-utf8 /usr/share/info/openocd.info.gz This I don't know enough about TexInfo stuff to answer - sorry. -Duane. ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Dean Glazeski wrote: Magnus Lundin wrote: Dean Glazeski wrote: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: E: missing-PT_GNU_STACK-section /usr/lib64/openocd/ecos/at91eb40a.elf openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/example.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.h openocd.x86_64: W: file-not-utf8 /usr/share/info/openocd.info.gz I think : The libddc files are for building target dcc implementations, and nothing in this list is used by the actual running openocd image on fedora. So this is really reference materials for developers. That might help you decide where to place them. Does this mean I can just remove them and be happy? Doing that definitely makes my life much simpler ;). Unless I hear otherwise, I'll rebuild the RPM without these later tonight (its 7pm where I'm at) and I'll throw the RPM up for review with Fedora tomorrow. Thanks! // Dean Glazeski I have no strong opinion but probably they should be included and go somewhere like /usr/lib/openocd/share/contrib or /usr/share/openocd/contrib/. In the neighboorhood of where all the target cfg files live . This is a bit dictated by Fedora policies. Regards, Magnus ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Duane Ellis wrote: Dean Glazeski wrote: Hey all, Can anyone give me insight on these files: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf /usr/lib64/openocd/ecos/at91eb40a.elf These are *TARGET* files, the package tool you have is *WRONG*HEADED*, or mis-informed - it sees the file as an ELF, then wrong assumes it is an *ELF* target for the intended HOST. You might want to ask the packaging people how to identify such files My hunch is, they have *NEVER* thought about this situation! The interesting thing about this is that Fedora is sort of hard set on following a filesystem hierarchy standard http://www.pathname.com/fhs/. What this basically means is that architecture specific files go into lib while architecture independent files belong in share. This means that all of the target scripts and this elf file should probably be installed into /usr/share/. I can use patches to fix this for the Fedora RPM if you can tell me how to tweak the build so that the files go elsewhere :). It might be good to consider fixing this to follow the FHS in the current head. openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/example.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.c openocd.x86_64: W: devel-file-in-non-devel-package /usr/share/openocd/contrib/libdcc/dcc_stdio.h Again, I think the package tool is wrong or mis-informed, this is a cross compilation package - these are example source files that a user of this tool might use - they are not *HOST* files, but are instead, *TARGET* files and are rightfully included in the package. Yeah, I don't know how to fix this one. It goes to the right area according to FHS, but it's being picked up as problematic (really just a warning). I'm searching around wiki pages, google, and IRC chats for answers. openocd.x86_64: W: file-not-utf8 /usr/share/info/openocd.info.gz This I don't know enough about TexInfo stuff to answer - sorry. -Duane. Thanks for the responses. // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
On Wed, 2009-05-20 at 21:43 -0500, Dean Glazeski wrote: Duane Ellis wrote: Dean Glazeski wrote: Hey all, Can anyone give me insight on these files: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf /usr/lib64/openocd/ecos/at91eb40a.elf These are *TARGET* files, the package tool you have is *WRONG*HEADED*, or mis-informed - it sees the file as an ELF, then wrong assumes it is an *ELF* target for the intended HOST. You might want to ask the packaging people how to identify such files My hunch is, they have *NEVER* thought about this situation! The interesting thing about this is that Fedora is sort of hard set on following a filesystem hierarchy standard. What this basically means is that architecture specific files go into lib while architecture independent files belong in share. This means that all of the target scripts and this elf file should probably be installed into /usr/share/. I can use patches to fix this for the Fedora RPM if you can tell me how to tweak the build so that the files go elsewhere :). It might be good to consider fixing this to follow the FHS in the current head. If you provide a list of difference between the actual/expected install paths for the files in question, I can take a look at the changes required for the autotools scripts. This should be easy to fix, and I am not opposed to doing it. Can such changes negatively affect others? Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] RPM Build
Zach Welch wrote: On Wed, 2009-05-20 at 21:43 -0500, Dean Glazeski wrote: Duane Ellis wrote: Dean Glazeski wrote: Hey all, Can anyone give me insight on these files: openocd.x86_64: E: statically-linked-binary /usr/lib64/openocd/ecos/at91eb40a.elf /usr/lib64/openocd/ecos/at91eb40a.elf These are *TARGET* files, the package tool you have is *WRONG*HEADED*, or mis-informed - it sees the file as an ELF, then wrong assumes it is an *ELF* target for the intended HOST. You might want to ask the packaging people how to identify such files My hunch is, they have *NEVER* thought about this situation! The interesting thing about this is that Fedora is sort of hard set on following a filesystem hierarchy standard. What this basically means is that architecture specific files go into lib while architecture independent files belong in share. This means that all of the target scripts and this elf file should probably be installed into /usr/share/. I can use patches to fix this for the Fedora RPM if you can tell me how to tweak the build so that the files go elsewhere :). It might be good to consider fixing this to follow the FHS in the current head. If you provide a list of difference between the actual/expected install paths for the files in question, I can take a look at the changes required for the autotools scripts. This should be easy to fix, and I am not opposed to doing it. Can such changes negatively affect others? Cheers, Zach What's interesting is that it appears that just about everything that goes into /usr/libqual is probably better suited in /usr/share. This is from a 0.1.0 perspective, but all of the TCL scripts, config scripts, and the pre-built elf (for ecos) and bin (for xscale) are all host architecture independent and should be in /usr/share. The config scripts, however, might have a better place in /etc/openocd or some such since they configure the operation of OpenOCD. I think this may affect some of the pieces that are looking for these TCL scripts and the config scripts, but I haven't looked into that stuff. Another question I had is if the source code for the static elf library and the bin is available. I thought I read somewhere about Fedora wanting the source for static libraries. I think there might be an exception for libraries that are compiled for other architectures, aka, ARM and XScale, but I figured it'd be good to find out now. // Dean Glazeski ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
