How did I manage to break this?!
Warner Losh
imp at bsdimp.com
Tue Jan 5 21:22:08 UTC 2016
It looks like this is unintended fallout from the abi variation stuff I
committed
a few days ago. I've disabled that and can no longer reproduce your problem.
Please try r293226 or newer. I'll keep this as a test case.
Warner
On Tue, Jan 5, 2016 at 1:42 PM, Warner Losh <imp at bsdimp.com> wrote:
> I'm reasonably sure you are right: armv6hf isn't involved for either
> one of us. It may be the pkg repo. There's a small chance that something
> I did to the linker may have caused this. Lemme build an image w/o
> the recent change to see if that's at fault.
>
> Warner
>
> On Tue, Jan 5, 2016 at 1:40 PM, Karl Denninger <karl at denninger.net> wrote:
>
>> I'm reasonably sure that armv6hf isn't involved; I canvassed the system
>> that was updated and unless I missed something really ridiculous there's
>> no hf-code left on the box.
>>
>> This looks like something got broken in the pkg repo that is being
>> picked up by the pkg utility... I can of course build the ports myself
>> but was hoping to not need to.
>>
>> On 1/5/2016 14:39, Warner Losh wrote:
>> > On a newly built nanobsd image that I hacked to allow enough space to
>> > install packages,
>> > I've recreated this problem with armv6hf being in the loop at all.
>> >
>> > Warner
>> >
>> > On Tue, Jan 5, 2016 at 1:06 PM, Karl Denninger <karl at denninger.net
>> > <mailto:karl at denninger.net>> wrote:
>> >
>> > $ readelf -h git
>> > ELF Header:
>> > Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>> > Class: ELF32
>> > Data: 2's complement, little endian
>> > Version: 1 (current)
>> > OS/ABI: NONE
>> > ABI Version: 0
>> > Type: EXEC (Executable file)
>> > Machine: ARM
>> > Version: 0x1
>> > Entry point address: 0xbe08
>> > Start of program headers: 52 (bytes into file)
>> > Start of section headers: 1623892 (bytes into file)
>> > Flags: 0x5000202, Version5 EABI, has
>> > entry
>> > point, software FP
>> > Size of this header: 52 (bytes)
>> > Size of program headers: 32 (bytes)
>> > Number of program headers: 8
>> > Size of section headers: 40 (bytes)
>> > Number of section headers: 28
>> > Section header string table index: 27
>> >
>> > And the allegedly-not-there shared library:
>> >
>> > ELF Header:
>> > Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
>> > Class: ELF32
>> > Data: 2's complement, little endian
>> > Version: 1 (current)
>> > OS/ABI: NONE
>> > ABI Version: 0
>> > Type: DYN (Shared object file)
>> > Machine: ARM
>> > Version: 0x1
>> > Entry point address: 0x1830
>> > Start of program headers: 52 (bytes into file)
>> > Start of section headers: 37324 (bytes into file)
>> > Flags: 0x5000202, Version5 EABI, has
>> > entry
>> > point, software FP
>> > Size of this header: 52 (bytes)
>> > Size of program headers: 32 (bytes)
>> > Number of program headers: 5
>> > Size of section headers: 40 (bytes)
>> > Number of section headers: 29
>> > Section header string table index: 26
>> >
>> >
>> >
>> > On 1/5/2016 14:00, Warner Losh wrote:
>> > > what dpes readelf -h on all the affected files tell you? You're
>> > most
>> > > interested in the line:
>> > >
>> > > Flags: 0x5000202, Version5 EABI, has
>> > > entry point, software FP
>> > >
>> > >
>> > > Warner
>> > >
>> > > On Tue, Jan 5, 2016 at 12:36 PM, Karl Denninger
>> > <karl at denninger.net <mailto:karl at denninger.net>
>> > > <mailto:karl at denninger.net <mailto:karl at denninger.net>>> wrote:
>> > >
>> > > $ uname -v
>> > > FreeBSD 11.0-CURRENT #0 r293189: Tue Jan 5 08:44:05 CST 2016
>> > >
>> > karl at NewFS.denninger.net:
>> /pics/CrossBuild/obj/arm.armv6/pics/CrossBuild/src/sys/RPI2
>> > >
>> > > Built a few hours ago, svn'd this morning. rm -r'd both the
>> > > object and
>> > > export directories before starting to prevent the risk of a
>> > > carry-over.
>> > >
>> > > And no, I pkg delete'd all the packages on the machine
>> > (including pkg
>> > > itself!) and then rm -r'd the entire /usr/local/lib directory,
>> > > then used
>> > > pkg to reload them.
>> > >
>> > > No chance they're leftovers.
>> > >
>> > > On 1/5/2016 13:33, Warner Losh wrote:
>> > > > what revision are you at?
>> > > >
>> > > > Could these be left-over hard-float libraries?
>> > > >
>> > > > Warner
>> > > >
>> > > > On Tue, Jan 5, 2016 at 12:27 PM, Karl Denninger
>> > > <karl at denninger.net <mailto:karl at denninger.net>
>> > <mailto:karl at denninger.net <mailto:karl at denninger.net>>
>> > > > <mailto:karl at denninger.net <mailto:karl at denninger.net>
>> > <mailto:karl at denninger.net <mailto:karl at denninger.net>>>> wrote:
>> > > >
>> > > > Went back from arm6hf to arm6 on a Pi2 (cross-built the
>> > > world and
>> > > > kernel, then rsync'd it), and now I'm getting this
>> > with two
>> > > packages
>> > > > that I loaded from the "pkg add" command (which,
>> > > incidentally, was the
>> > > > reason to do it in the first place, since arm6hf has
>> > no package
>> > > > repository)
>> > > >
>> > > > The system itself is running fine.
>> > > >
>> > > > $ git
>> > > > Shared object "libintl.so.8" not found, required by
>> "git"
>> > > >
>> > > > Bee-ess
>> > > >
>> > > > $ ldconfig -r|grep intl
>> > > > 134:-lintl.8 => /usr/local/lib/libintl.so.8
>> > > > 135:-lintl.9 => /usr/local/lib/libintl.so.9
>> > > >
>> > > > $ ls -al /usr/local/lib/*intl*
>> > > > -rw-r--r-- 1 root wheel 74122 Dec 7 12:58
>> > > /usr/local/lib/libintl.a
>> > > > lrwxr-xr-x 1 root wheel 16 Dec 7 12:58
>> > > > /usr/local/lib/libintl.so
>> > > > -> libintl.so.8.1.4
>> > > > lrwxr-xr-x 1 root wheel 16 Dec 7 12:58
>> > > > /usr/local/lib/libintl.so.8 -> libintl.so.8.1.4
>> > > > -rw-r--r-- 1 root wheel 51832 Dec 7 12:58
>> > > > /usr/local/lib/libintl.so.8.1.4
>> > > > lrwxr-xr-x 1 root wheel 12 Dec 7 12:58
>> > > > /usr/local/lib/libintl.so.9 -> libintl.so.8
>> > > >
>> > > > That all came in from the pkg add, so why is the loader
>> > > > complaining that
>> > > > libintl.so.8 not there? Incidentally, bash throws up
>> > on the
>> > > same
>> > > > error.
>> > > >
>> > > > --
>> > > > Karl Denninger
>> > > > karl at denninger.net <mailto:karl at denninger.net>
>> > <mailto:karl at denninger.net <mailto:karl at denninger.net>>
>> > > <mailto:karl at denninger.net <mailto:karl at denninger.net>
>> > <mailto:karl at denninger.net <mailto:karl at denninger.net>>>
>> > > > <mailto:karl at denninger.net <mailto:karl at denninger.net>
>> > <mailto:karl at denninger.net <mailto:karl at denninger.net>>
>> > > <mailto:karl at denninger.net <mailto:karl at denninger.net>
>> > <mailto:karl at denninger.net <mailto:karl at denninger.net>>>>
>> > > > /The Market Ticker/
>> > > > /[S/MIME encrypted email preferred]/
>> > > >
>> > > >
>> > >
>> > > --
>> > > Karl Denninger
>> > > karl at denninger.net <mailto:karl at denninger.net>
>> > <mailto:karl at denninger.net <mailto:karl at denninger.net>>
>> > > <mailto:karl at denninger.net <mailto:karl at denninger.net>
>> > <mailto:karl at denninger.net <mailto:karl at denninger.net>>>
>> > > /The Market Ticker/
>> > > /[S/MIME encrypted email preferred]/
>> > >
>> > >
>> >
>> > --
>> > Karl Denninger
>> > karl at denninger.net <mailto:karl at denninger.net>
>> > <mailto:karl at denninger.net <mailto:karl at denninger.net>>
>> > /The Market Ticker/
>> > /[S/MIME encrypted email preferred]/
>> >
>> >
>>
>> --
>> Karl Denninger
>> karl at denninger.net <mailto:karl at denninger.net>
>> /The Market Ticker/
>> /[S/MIME encrypted email preferred]/
>>
>
>
More information about the freebsd-arm
mailing list