Re: [osol-discuss] gcc compilation problem after upgrade to solaris 11.0
On 12/10/11 4:20 AM, Bruno Damour wrote: Hello, I upgraded some time ago from solaris 11 express to solaris 11.0. I have a gcc/gnu installation built from sources in a zone. I've discovered that trying now to compile doesn't work any longer. Typically, configure fails with a message seaming to guess that I'm trying to cross compile without providing a --host option. I sort of guess this is related to solaris 11 now beeing 64bit only ? Doesn anyone know how I could recover a working gcc (apart from installing the ips provided gcc which is gcc-4.5.2 and recompiling my gcc 4.6.2) ? Thanks for any hint Bruno ... configure:6049: gcc -o conftest -I/usr/local/include -L/opt/local/lib -R/opt/local/lib conftest.c 5 conftest.c:17:19: fatal error: stdio.h: No such file or directory This has nothing to do with Solaris being 64-bit only. All that means is that there's no longer a 32-bit kernel. Most people haven't run the 32-bit kernel for years, as x86 hardware has been able to support 64-bits for a long time. Rest assured that S11's ability to run 32-bit code in natively in userland is still there. It's been ages since I built gcc, but I think that the messages about cross compiling are just part of the process it goes through. Had the test compile worked, it would likely have determined that it wasn't building a cross compiler. I think the error message about not finding stdio.h is likely at the root of things. Have you installed the system header files? # pkg search -r /usr/include/stdio.h # INDEX ACTION VALUE PACKAGE # path file usr/include/stdio.h pkg:/system/header@0.5.11-0.175.0.0.0.2.1 # pkg install system/header - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
On 10/20/10 21:42, Richard L. Hamilton wrote: While I still like the idea of a runtime function (new syscall or extension to mprotect()) to control default stack or heap permissions (mainly for use with a preloadable shared object to apply to existing binaries that don't have a spare program header, although some other runtime uses might be imaginable), leaving oneself the leeway to patch a binary statically also seems desirable. I gather that something had been done to leave some room so that for newer binaries, one could patch in runpath changes longer than the original runpath (whereas for older ones, one might well have been limited to a new runpath that fit in the same space as the old one). Are there any _current_ uses you can see for a spare unused (PT_NULL) program header other than changing it into a PT_SUNWSTACK header? (I imagine that there's always a good chance that future uses as yet unsupported might turn up, i.e. some future feature that could be retrofitted into existing binaries given a spare header to put it into; but I'm thinking now in terms of current possibilities.) The something was 6516118 Reserved space needed in ELF dynamic section and string table PSARC 2007/127 Reserved space for editing ELF dynamic sections This is definitely a similar idea, elfedit being the common thread. I don't see another use for a spare program header, other than for this SUNWSTACK purpose, at this time. However, the cost of an extra program header is nil, so that doesn't worry me. We'll see... - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
On 10/20/10 3:39 AM, casper@sun.com wrote: I had a few minutes today to try an experiment, and I'm afraid the idea of having ld always generate a PT_SUNWSTACK is a non-starter. The problem is that it overrides the behavior of 'set noexec_user_stack=1' in /etc/system, and can therefore quietly allow programs that would not previously been able to execute on the stack do so. Thanks for this investigation. There is another issue we haven't explored is the use a system call; there's a sysconf(_SC_STACK_PROT) but there's no way to set in on the fly. If we create a function to change it on the fly, we could make a LD_PRELOAD object which enforce it. The current mapped pages would not be protected but threadstacks and additional pages would be rw-. Casper Yet another possibility would be for ld to issue an extra PT_NULL program header, rather than a PT_SUNWSTACK. PT_NULL is a no-op, and would not alter behavior, but elfedit can be later be used to turn it into something else, such as PT_SUNWSTACK. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
On 10/17/10 10:01, Ali Bahrami wrote:
I've had the same thought about having ld always generate
a PT_SUNWSTACK, and even sent some internal email yesterday
proposing it to my fellow linker alien. It's actually simpler
than what we do now, since we'd just remove the code that
checks the header flags against the ABI defaults before issuing
the header. It seems reasonable to me, and we'll see what others think.
I had a few minutes today to try an experiment, and I'm afraid
the idea of having ld always generate a PT_SUNWSTACK is a non-starter.
The problem is that it overrides the behavior of 'set noexec_user_stack=1'
in /etc/system, and can therefore quietly allow programs that would
not previously been able to execute on the stack do so.
I used the following test program to play with this.
--
#include stdio.h
#include strings.h
/*
Code bytes for
static void f(void) { }
obtained by compiling with 'cc -Kpic', and using dis to disassemble.
f: 55 pushl %ebp
f+0x1: 8b ec movl %esp,%ebp
f+0x3: 83 ec 04 subl $0x4,%esp
f+0x6: 89 5d fc movl %ebx,-0x4(%ebp)
f+0x9: 8b 5d fc movl -0x4(%ebp),%ebx
f+0xc: c9 leave
f+0xd: c3 ret
0x80509ee: 90 nop
0x80509ef: 90 nop
*/
unsigned char fbuf[] = {
0x55,
0x8b, 0xec,
0x83, 0xec, 0x04,
0x89, 0x5d, 0xfc,
0x8b, 0x5d, 0xfc,
0xc9,
0xc3,
0x90,
0x90
};
int
main(int argc, char **argv)
{
double buf[(sizeof(fbuf) + 7) / 8];
void (* fp)(void);
bcopy((void *) fbuf, buf, sizeof(fbuf));
fp = (void *) buf;
(*fp)();
printf(DONE\n);
return (0);
}
--
I then put the following in /etc/system on my X86 system, and rebooted:
set noexec_user_stack=1
set noexec_user_stack_log=1
On my system:
% cc main.c
main.c, line 44: warning: assignment type mismatch:
pointer to function(void) returning void = pointer to void
% ./a.out
Segmentation Fault (core dumped)
This is what you'd expect: The a.out, and the IA32 ABI allow an executable
stack, but the kernel denies it due to noexec_user_stack. Running the same
executable on a system without the /etc/system setting, it works:
% ./a.out
DONE
Back on my system, let's give it a PT_SUNWSTACK, and disable the executable
stack:
% cc -Kpic -M /usr/lib/ld/map.noexstk main.c
main.c, line 40: warning: assignment type mismatch:
pointer to function(void) returning void = pointer to void
% ./a.out
Segmentation Fault (core dumped)
And using elfedit to modify the stack header, we can make this program
run to completion:
% elfedit -e 'phdr:p_flags -or sunwstack x' a.out
% ./a.out
DONE
Note that we've still got noexec_user_stack set. Putting this all together,
it appears that exec() uses the following rules when setting up the stack
for an executable:
1) Initialize stack protections to ABI default for platform
2) If noexec_user_stack is set, remove the execute bit from
the stack permissions.
3) If the executable has a PT_SUNWSTACK header, replace the stack
permissions with those given by the header.
So I'm imagining a system out there, in production, with noexec_user_stack set.
This system has a bunch of executables built with the ld defaults, and so, these
objects have no PT_SUNWSTACK. Two things happen:
1) The system is upgraded, and has our new ld that always
issues PT_SUNWSTACK.
2) The executables are rebuilt on this new system.
The result is that programs on this production system that would previously
not have been allowed to execute code on the stack will now be allowed to do
so. And this will have happened happened without anyone thinking about the
security implications, or even being aware that they should. That's bad.
Until there's a consensus that Solaris should ignore the platform ABI,
I think we're back to the original assertion that the best you can do is
to always link with -M /usr/lib/ld/map.noexstk, and to set noexec_user_stack.
Since executables that need an executable stack are rare, another answer
is to always set noexec_user_stack, and to insist that programs that need
an executable stack must have a PT_SUNWSTACK that makes it so.
- Ali
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
On 10/17/10 4:58 AM, Richard L. Hamilton wrote: While it doesn't help existing binaries, would it be possible to for new 32-bit binaries persuade the linker to issue a redundant (same as ABI) PT_SUNWSTACK header? That I suppose elfedit _would_ be able to change after-the-fact. I gather one could do it indirectly, by linking with -M /usr/lib/ld/map.noexstk and then restoring stack execute permission with elfedit (so that someone could take it away again later if they wanted to), but that's clearly silly. [Update] I just tried back on SXCE snv_97 (still haven't updated) with a map file containing stack = STACK ?RWX; and that appeared to work - the header was generated with the requested permissions. So it ought to be rather easy to change the linker to just generate the header explicitly by default. The point would be if inserting the seemingly redundant header could happen by default, which would allow someone to correct the developer's omission of turning off stack execute permission when linking. OTOH, I suppose elfedit would mess with signed executables (not that they're that big a deal until enforcement is generally available). And of course, whenever reasonably expected calculations involving future times would pass the Jan 19 03:14:07 2038 mark, the existing 32-bit ABI would be broken anyway. (to figure out something involving a 30 year mortgage, that would already have been a problem for a couple of years now...) Too bad larger time_t wasn't part of largefile support. I've had the same thought about having ld always generate a PT_SUNWSTACK, and even sent some internal email yesterday proposing it to my fellow linker alien. It's actually simpler than what we do now, since we'd just remove the code that checks the header flags against the ABI defaults before issuing the header. It seems reasonable to me, and we'll see what others think. I don't view the fact that elfedit breaks the signature of an object as a problem. If we deliver an object with an executable stack, and it's modified in the field, that's the sort of thing you'd want to detect. You can certainly cause ld to inject a redundant header yourself, using a mapfile. However, as you pointed out earlier in this thread, it's a rare application that really needs an executable stack. So if you're aware enough of the issue to be able to arrange for a PT_SUNWSTACK to be added to the object with a mapfile, you might as well and make it non-executable, rather than the redundant one. The redundant header is only really helpful if it's always put there by ld as a default action. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] 32-bit noexec_user_stack on per-process basis?
On 10/16/10 08:54 AM, Richard L. Hamilton wrote: Doesn't help with existing binaries, but it's good to know for when one can re-link. If there's a way to construct an LD_PRELOAD'able shared object to do the trick for existing binaries, I don't see how given the description of mprotect(2), to specify the entire present (and future) stack or heap of a process. From some of the stuff I've looked at, it seems that executables were first widely built to disable an executable stack (using something as boring as /usr/bin/who as the test case) in Solaris 9; on Solaris 8, I didn't see a program header for the stack for the who executable, but when I recompiled with the -M option you gave, and checked the new binary with elfdump, I saw the additional program header. There are a few oddball programs that legitimately want a segment that's both writable and executable (because they compile on-the-fly); some LISP interpreters used to do that, I think; and I can imagine that some Forth implementations might want to do strange things. (I wonder if the JVM does anything like that?) But I suppose they ought to create an explicit anonymous mapping with the permissions they desire for that use. I believe you've already covered the essential facts, so allow me to toss out some related supplemental trivia... The stack permissions are set up within exec, based on the executable's PT_SUNWSTACK program header, 'set noexec_user_stack' in /etc/system, and failing those, the ABI mandated default. The stack headers that come in later with other objects don't have a vote in this, and their PT_SUNWSTACK headers are ignored, including PRELOAD objects. Another point of trivia is that if you have an executable with a PT_SUNWSTACK, you can use elfedit to make its stack executable: % elfedit -e 'phdr:p_flags -or sunwstack x' /bin/ls my.ls % elfdump -p my.ls Program Header[6]: p_vaddr: 0 p_flags:[ PF_X PF_W PF_R ] p_paddr: 0 p_type: [ PT_SUNWSTACK ] p_filesz: 0 p_memsz:0 p_offset: 0 p_align:0 Unfortunately, the reverse is generally not possible: ld doesn't issue a PT_SUNWSTACK when the permissions match the ABI defaults, so there's nothing there for you to edit. When I introduced the new mapfile syntax for ld earlier this year, the question of whether we could change the default to make stacks non-executable came up. I asked around, and the general consensus seemed to be that while no one wants an executable stack, that going against the ABI seemed to be a step too far. All of which seems to say that linking with -M /usr/lib/ld/map.noexstk is about the best you can currently do. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Doc for build upgrade
On 09/02/10 08:18, Rob McMahon wrote: On 02/09/2010 12:30, Rob McMahon wrote: Eric Andersen wrote: If you want to build the official Oracle ON, I don't know. I think you need access to closed bits of the OS. If you want to move to the Illumos ON, there are instructions here (at least to get you to 145, not sure about 146): http://illumos.org/projects/illumos-gate/wiki/How_To_Build_illumos I've just been trying this, and it all went without a hitch up to the point where you're supposed to reboot into 145. I have not errors, and I'm in the new boot environment: os-devel_145 NR / 86.05G static 2010-09-02 11:42 but uname still says snv_134, which doesn't sound right to me. I'm going to continue with the code download and build, but I'm suspicious now. Okay, sorry to reply to myself, but I think this is terminal. `dmake setup' fails with ld: fatal: .../illumos-gate/usr/src/common/mapfiles/common/map.noexstk: 31: expected a `=', `:', `|', or `@' *** Error code 1 dmake: Fatal error: Command failed for target `cw' This line is $mapfile_version 2 So I suspect I'm running an old version of ld. `ld' is ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1689 Can someone confirm that this should have been updated with the move from 134 - 145, and let me know what version the ld in that release should be. onu.sh under the new BE says No updates available for this image. Any tips (even a works for me sent to me off list would be an encouragement to go back and see where I went wrong). Cheers, Rob Hi Rob, The necessary support for the new mapfiles integrated in snv_135. It does look like your build system is still at 134. Sorry, I don't have the ld version # for 135 handy, but you can test by looking for a symbol that was introduced with this change: % elfdump -sN.dynsym /lib/liblddbg.so.4 | grep Dbg32_map_cexp_id [380] 0x0001090c 0x006c FUNC GLOB D2 .text Dbg32_map_cexp_id If you get output like the above, you've got the new mapfile support. If you get no output, then you don't. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Community distro, teamwork and being clear
On 07/22/10 14:19, Paul Gress wrote:
On 07/22/10 04:35 AM, Dennis Clarke wrote:
See :
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/sgs/packages/common/SUNWonld-README
Note that there is specific references to Solaris 8 and Solaris 10
update 10 and Nevada and even Solaris Nevada (OpenSolaris 2009.06,
snv_111) but there is no such thing as OpenSolaris 2010.xx and there
never will be.
Anything we have heard about a 2010 release of OpenSolaris is just a
pack of lies.
Prove me wrong if you can.
Maybe not prove wrong, but cast doubt.
Near the bottom there is just a heading Solaris Nevada. If I look at
some of the bug id's, they have the latest ones, not used in earlier
revisions. Maybe Solaris Nevada means latest or there's an official
release planned called just Solaris Nevada.
Paul
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Paul,
That's right. Nevada just means mercurial tip to us.
It's just a codename for Future Release With Unknown Name And Date.
Nevada is easier to say... :-)
SUNWonld-README is how we keep track of what's found under
usr/src/cmd/sgs. It tracks what we've done, what it got back ported to,
and so on. In the case of OpenSolaris, we generally make a new entry after
a release has happened, and move the relevant lines up from the bottom of
the file. Hence, no OpenSolaris 2010.xx entry means nothing more than that it
hasn't happened. SUNWonld-README is clearly not a marketing document.
That's why it's checked in with the code.
I understand the temptation to read more into it than that, but
that's all it is.
I'd also like to clarify that linkers.{central,sfbay} is a server
we use to hold our files. It is 99% ABI documents (available via
google) or obsolete planning documents. Anything on it with
value to the community has probably been covered on one of our blogs,
which are full of information you'd be hard pressed to find elsewhere.
- Ali
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Using opensolaris 134 and sunstudio compiler
Andre Lue wrote: getting ld: fatal: file smartd.o: wrong ELF class: ELFCLASS64 when trying to build 64 bit versions of programs for most things where the 32 bit version builds fine. gmake all-recursive gmake[1]: Entering directory `/home/andre.l/smart/smartmontools-5.38' Making all in . gmake[2]: Entering directory `/home/andre.l/smart/smartmontools-5.38' source='utility.cpp' object='utility.o' libtool=no \ DEPDIR=.deps depmode=none /usr/bin/bash ./depcomp \ CC -DHAVE_CONFIG_H -I. -DSMARTMONTOOLS_SYSCONFDIR=\/usr/local/etc\ -m64 -erroff=%none,wbadinitl,wbadasgl,badargtypel2w -xO2 -library=no%Cstd,no%Crun -c -o utility.o utility.cpp source='os_solaris.cpp' object='os_solaris.o' libtool=no \ DEPDIR=.deps depmode=none /usr/bin/bash ./depcomp \ CC -DHAVE_CONFIG_H -I. -DSMARTMONTOOLS_SYSCONFDIR=\/usr/local/etc\ -m64 -erroff=%none,wbadinitl,wbadasgl,badargtypel2w -xO2 -library=no%Cstd,no%Crun -c -o os_solaris.o os_solaris.cpp CC -erroff=%none,wbadinitl,wbadasgl,badargtypel2w -xO2 -library=no%Cstd,no%Crun -library=no%Cstd,no%Crun -o smartd smartd.o atacmdnames.o atacmds.o ataprint.o knowndrives.o scsicmds.o scsiata.o scsiprint.o utility.o os_solaris.o -lnsl ld: fatal: file smartd.o: wrong ELF class: ELFCLASS64 ld: fatal: file processing errors. No output written to smartd gmake[2]: *** [smartd] Error 1 gmake[2]: Leaving directory `/home/andre.l/smart/smartmontools-5.38' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/home/andre.l/smart/smartmontools-5.38' gmake: *** [all] Error 2 for d in `ls *.o`; do file $d; done atacmdnames.o: ELF 64-bit LSB relocatable AMD64 Version 1 atacmds.o: ELF 64-bit LSB relocatable AMD64 Version 1 [CMOV] ataprint.o: ELF 64-bit LSB relocatable AMD64 Version 1 [CMOV] knowndrives.o: ELF 64-bit LSB relocatable AMD64 Version 1 [CMOV] os_solaris.o: ELF 64-bit LSB relocatable AMD64 Version 1 [CMOV] scsiata.o: ELF 64-bit LSB relocatable AMD64 Version 1 [CMOV] scsicmds.o: ELF 64-bit LSB relocatable AMD64 Version 1 [CMOV] scsiprint.o:ELF 64-bit LSB relocatable AMD64 Version 1 [SSE2 CMOV] smartd.o: ELF 64-bit LSB relocatable AMD64 Version 1 [SSE CMOV] utility.o: ELF 64-bit LSB relocatable AMD64 Version 1 [CMOV] if I recompose the failure line and add -m64 it completes. Am I doing something wrong or is there something wrong with the code? Can someone guide me on a proper fix for this? CC -erroff=%none,wbadinitl,wbadasgl,badargtypel2w -m64 -xO2 -library=no%Cstd,no%Crun -library=no%Cstd,no%Crun -o smartd smartd.o atacmdnames.o atacmds.o ataprint.o knowndrives.o scsicmds.o scsiata.o scsiprint.o utility.o os_solaris.o -lnsl This is the env used: export CC=/opt/SUNWspro/bin/cc export CCX=/opt/SUNWspro/bin/CC export CONFIG_SHELL=/usr/bin/bash export PATH=/opt/SUNWspro/bin:/usr/bin:/usr/sbin:/usr/ccs/bin:/usr/ucb ulimit -s 32768 export CXXFLAGS= -library=no%Cstd,no%Crun export LDFLAGS= -library=no%Cstd,no%Crun export CFLAGS= -m64 export CPPFLAGS= -m64 Just a guess, but I bet that if you add a '-dryrun' option to your CC line, you'll see that the compiler is adding one or more 32-bit objects at the head of the command line that it feeds to the linker. The linker decides what type of object it's building based on the first object on the command line, so if I'm right about the above, then that 32-bit object is going to cause ld to complain when it encounters your 64-bit objects. The right fix is to tell the compiler to produce a 64-bit object with -m64 as you've done. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris gcc but gnu-ld
On 07/11/10 07:40, Günther Schmidt wrote: Hi all, is it possible to make Sun's gcc-3.4.3 use the gnu linker instead of the hard-wired Sun ld? Günther Hi Günther, From reading the rest of this thread, I gather that the GNU ld -x option is the problem. -x --discard-all Delete all local symbols. We're always interested in adding support for GNU options that are compatible with the Solaris ld, so next time something like this comes up, you might consider sending a message to the tools-linking OpenSolaris list. I'm guessing that the use of -x is not essential to building this executable, so one workaround might be to simply edit the Makefile(s) produced by configure to remove it. Or, I think the Solaris ld -zredlocsym option seems to do the same thing --- you might try replacing the use of -x with that. Perhaps configure could even be updated to do that substitution, if you're interested in feeding GNU changes upstream to their package implementors. Both of the above involve some hacking, but I think you're going to have far more luck that way, rather than symlinking /usr/bin/ld to point at the GNU ld. The two linkers are not plug compatible (as you've seen), though there is substantial overlap. On top of the obvious reasons not to do this, gcc is built knowing which linker it is using (Solaris or GNU), and if you switch the linker out without rebuilding gcc, you'll probably hit other harder issues. For my part, I'll look into making -x an alias for -z redlocsym in the Solaris ld. That won't help you immediately, but will knock down one more obstacle going forward. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris gcc but gnu-ld
On 07/12/10 14:37, Günther Schmidt wrote: Hi Ali, as it turns out everything went fine, ie. the compilation of ghc (6.10.4) succeeded without problems. The configure script was already set to check whether ld understood the -x option or not, but it chose the ld it found in the path, which was the gnu-ld. Once I reordered my path the configure script saw that it was /usr/bin/ld which doesn't accept -x it acted accordingly. Best regards Günther Awesome! I'm glad to hear you're back on track. I'll have to remember that one... :-) It sounds like configure is using the wrong test. Rather than ask which ld is in the users path, it should be asking which ld the compiler is configured to use. Of course, that's probably a much harder question to answer in full generality... - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris gcc but gnu-ld
On 07/12/10 15:00, Rainer Orth wrote: Ali Bahramiali.bahr...@oracle.com writes: It sounds like configure is using the wrong test. Indeed, this is plain nonsense. Rather than ask which ld is in the users path, it should be asking which ld the compiler is configured to use. Of course, that's probably a much harder question to answer in full generality... Not at all :-) $ gcc -print-prog-name=ld /usr/ccs/bin/ld Or, better yet, run the test with gccld option, or, it it isn't passed through, gcc -Wl,ld option. Second-guessing the compiler is guaranteed to fail. Hope this helps. Rainer Full generality would include handling non-gcc compilers, and environment variables like LD_ALTEXEC. But really, we're talking about gcc here, so yeah, I agree. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] open source apps on Solaris OpenSolaris Nevada etc.
Dennis Clarke wrote:
ELF Header
ei_magic: { 0x7f, E, L, F }
ei_class: ELFCLASS32 ei_data: ELFDATA2LSB
ei_osabi: ELFOSABI_SOLARISei_abiversion: EAV_SUNW_CURRENT
e_machine: EM_386 e_version: EV_CURRENT
e_type: ET_EXEC
e_flags: 0
e_entry: 0x8056800 e_ehsize: 52 e_shstrndx: 36
e_shoff: 0x6a5d0 e_shentsize: 40 e_shnum: 37
e_phoff: 0x34 e_phentsize: 32 e_phnum: 6
Anyone know what ELFOSABI_SOLARIS is ?
Well, yes...
When I enter ELFOSABI_SOLARIS into google, the first hit is
the Nevada CR under which it was integrated, and the second is the
PSARC case.
If you read the PSARC case, you'll see that ei_osabi and ei_abiversion
are ELF header fields that have always been there, which we have begun
to tag correctly for our platform, and which are ignored by the
runtime.
Since they're ignored by ld.so.1, this shouldn't be a concern. Has
this change caused a problem?
Well what happens if you take that binary and try to run it on Solaris 10?
You can take an old object to a new system (which you also discuss), but taking
an object built on a new system to run on an older system has never been
supported as far as I know. I'm confused about what you're trying to
show with this point.
Regards
- Ali
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] OpenSolaris, Solaris 10, SXCE, Indiana: which to use for a developer?
Jürgen Keil wrote: On Sat, Jan 02, 2010, Jürgen Keil wrote: [OpenSolaris Indiana: GNU?] Well, it does have both the gnu utilities (/usr/gnu/bin) and the solaris counterparts, and in the default setup the /usr/gnu/bin directory is ahead of /usr/bin in $PATH. I simply removed /usr/gnu/bin from $PATH, but I still got vim instead of vi[1] (in /usr/bin AFAIR), Yep, that's true. OpenSolaris does not have the real vi. Not sure what the reason is; the source seems be available in the onnv mercurial repository, so I guess the real vi would be re-distributable with OpenSolaris. and bash as root sh. Ok, so change root's shell in /etc/passwd. If there is a way to configure OpenSolaris to be(have) like Sun's Solaris (for which I develop software and to which I'm used (besides *BSD)), then please let me know. If you target Solaris 10, then you should probably run Solaris 10 on your development system, too. The old vi and Bourne shell (sh) are in /usr/has/bin. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] ld: fatal: Error 1 running make on libiconv 1.13.1
Pen-Yuan Hsing wrote: Hello, I am trying to compile and install the latest libiconv 1.13.1 (downloaded directly from the official GNU site) on my installation of i386 OpenSolaris 2009.06. 1. [i]./configure --prefix=/usr/gnu --enable-shared --with-pic[/i] 2. [i]make[/i] ends with this error: libtool: link: gcc -shared -Wl,-z -Wl,text -Wl,-h -Wl,libiconv.so.2 -o .libs/libiconv.so.2.5.0 .libs/iconv.o .libs/localcharset.o .libs/relocatable.o -lsec -lc Text relocation remains referenced against symbol offset in file aliases_lookup 0x129a6 .libs/iconv.o aliases_lookup 0x12ee4 .libs/iconv.o [b]ld: fatal: relocations remain against allocatable but non-writable sections[/b] collect2: ld returned 1 exit status make[1]: *** [libiconv.la] Error 1 make[1]: Leaving directory `/src/libiconv-1.13.1/lib' make: *** [all] Error 2 I have the latest binutils installed (2.20) and GCC 4.3.2 from Package Manager. Also, the following configure options have been unsuccessfully atttempted: ./configure --prefix=/usr/gnu --enable-shared ./configure --prefix=/usr/gnu --with-pic ./configure --prefix=/usr/gnu Any help would be appreciated! Thanks. libtool is passing ld the option '-z text'. This option, which is a very good thing to use, tells the link-editor to disallow relocations against readonly text: -z text In dynamic mode only, forces a fatal error if any relo- cations against non-writable, allocatable sections remain. For historic reasons, this mode is not the default when building an executable or shared object. However, its use is recommended to insure that the text segment of the dynamic object being built is shareable between multiple running processes. A shared text seg- ment incurs the least relocation overhead when loaded into memory. The use of -ztext is not your problem --- it's simply allowing the linker to catch the problem, which is that the object iconv.o has relocations against the text segment. The most likely reason for this is that .libs/iconv.o was not compiled PIC. I recommend starting with a fresh clean workspace, and when you build it, capture all the output into a log file that you can examine later: make 21 | tee output.log and then look at the output.log file and note which flags are being passed to the compiler. You'll want to see an option like -pic, -fpic, -Kpic, or -KPIC, depending on the compiler. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] emacs mappings on opensolaris
Harry Putnam wrote: When I first started using opensolaris about a yr ago... some kind soul here told me how to set things up so that emacs works like it does on linux. Not having to use Esc-x instead of M-x for example.. and so that backspc does delete to the left... I don't recall if there was more but I've lost my notes about this... and my old .emacs file that contained it. I wonder if someone can coach me a bit before I commit suicide, or take an axe to RMS. (That may not be a smart thing to say on a solaris OS hehe). ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org Is this it? http://www.mail-archive.com/opensolaris-discuss@opensolaris.org/msg38090.html It was the first thing google brought up when I entered Harry Putnam emacs solaris. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [zfs-discuss] Which kind of ACLs does tmpfssupport?
Roland Mainz wrote: Umpf... the matching code is linked with -Bdirect ... AFAIK I can't interpose library functions linked with this option, right ? You could set LD_NODIRECT to defeat direct bindings --- see ld.so.1(1). However, I agree with the thought that it would be easier to just have a ZFS filesystem to test against. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] How Best to Handle
Daniel Templeton wrote: snip 2) Offer a single package that includes all the tuned libraries under a sub-directory and provide a way to switch among them, such as the modules command (which is on our list of things to port). This sounds like a pretty good match for hardware capabilities. You can produce multiple versions of your libraries, each tagged with their specific hardware requirements, and then produce a shared object filter on top of them. The runtime linker will select the best library to actually load at runtime, based on your end user's hardware. Here's a blog that Rod wrote about the subject of object filters: http://blogs.sun.com/rie/entry/shared_object_filters and the Solaris Linker and Libraries guide has some information on the subject also: http://docs.sun.com/app/docs/doc/817-1984 This will work, as long as the options you want to use correspond to the defined hardware capability bits. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Problems compiling Build 87
Joerg Schilling wrote: Is this expected or did I do something wrong: Check ELF runtime attributes ./lib/amd64/libc.so.1: .SUNW_dynsymsort: duplicate 0x0015a500: $dtrace30275.mutex_lock_kernel, mutex_lock_kernel ./lib/amd64/libc.so.1: .SUNW_dynsymsort: duplicate 0x0015aa90: $dtrace30275.mutex_trylock_adaptive, mutex_trylock_adaptive ./lib/amd64/libc.so.1: .SUNW_dynsymsort: duplicate 0x0015adc0: $dtrace30275.mutex_trylock_process, mutex_trylock_process ./lib/amd64/libc.so.1: .SUNW_dynsymsort: duplicate 0x0015b260: $dtrace30275.mutex_unlock_queue, mutex_unlock_queue ./lib/amd64/libc.so.1: .SUNW_dynsymsort: duplicate 0x0015b300: $dtrace30275.mutex_unlock_process, mutex_unlock_process ./lib/amd64/libc.so.1: .SUNW_dynsymsort: duplicate 0x0015b660: $dtrace30275.mutex_recursion, mutex_recursion ./lib/amd64/libc.so.1: .SUNW_dynsymsort: duplicate 0x0015bda0: mutex_lock_impl, $dtrace30275.mutex_lock_impl ./lib/libc.so.1: .SUNW_dynsymsort: duplicate 0x000a7c30: $dtrace32271.mutex_lock_kernel, mutex_lock_kernel ./lib/libc.so.1: .SUNW_dynsymsort: duplicate 0x000a8144: mutex_trylock_adaptive, $dtrace32271.mutex_trylock_adaptive ... Jörg Those check_rtime messages are informational, and won't affect the correctness of your builds. To eliminate them, you need to use a linker that includes both of these: 6602451 new symbol visibilities required: EXPORTED, SINGLETON and ELIMINATE 6630135 symbols created for dtrace -G should be removed in the final link This means snv_79 or newer for your build system. You should get none of these SUNW_XXXsort messages after that. If you do get a few, those would be from your own code, as discussed in http://in.opensolaris.org/os/community/on/flag-days/pages/2007012501/ Let me know if this doesn't cover your case. Thanks... - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] BSD vs SYSV ps (was [osol-announce] No update on SXCE Build 79)
[EMAIL PROTECTED] wrote: Agreed, especially since both ps's are really the same program: % ls -ilF /usr/bin/ps /usr/ucb/ps 198275 -r-xr-xr-x 71 root bin 8164 Jan 27 02:11 /usr/bin/ps* 198275 -r-xr-xr-x 71 root bin 8164 Jan 27 02:11 /usr/ucb/ps* No, not really. (Both are called through an indirect isaexec wrapper and that is the link you are seeing (with 71 links) Casper Well shoot, the size and link count are dead giveaways. sigh Sorry about the bogus claim. I'll back down to since we already have code for both. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] BSD vs SYSV ps (was [osol-announce] No update on SXCE Build 79)
James Carlson wrote:
[EMAIL PROTECTED] writes:
One particular annoyance of mine being that it is fairly easy to write a
single ps which does both ps -ef and ps uxga.
Not only easy to write, but that's the default on other OSes. (AIX
had that a decade or more ago. :-)
That's one of the sorts of things that are hard to fix, even though
easy to write. It's not a big project, and you can't point to $1e9 of
new revenue to fix minor annoyances, so it has to be done in someone's
copious free time.
Agreed, especially since both ps's are really the same program:
% ls -ilF /usr/bin/ps /usr/ucb/ps
198275 -r-xr-xr-x 71 root bin 8164 Jan 27 02:11 /usr/bin/ps*
198275 -r-xr-xr-x 71 root bin 8164 Jan 27 02:11 /usr/ucb/ps*
I'm sure we'll get this done eventually... :-)
In the meantime: I was whining about this to Andy Rudoff a few years ago,
and he quickly came back with the following csh alias to paper over
the difference:
# Use /usr/ucb/ps if there is no argument starting with a -
alias ps '(if (\!* == ) exec /usr/bin/ps; if (\!* =~ -*) exec
/usr/bin/ps
\!*; exec /usr/ucb/ps \!*)'
Later, I put this into my .bashrc:
# Use /usr/ucb/ps if there are arguments and they start without a '-'.
# This lets me cling to to the BSD flags while still having standard
# ps available.
function ps() {
case $1 in
-*|)
/usr/bin/ps $*
;;
*)
/usr/ucb/ps $*
;;
esac
}
I still think we should adopt the merged behavior, but this has
made my fingers happy for several years now.
- Ali
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Solaris 11 release timing (or should I run Solaris 10 on a laptop?)
Sergio Enrique Schvezov wrote: Maybe things have changed... [i]Here at IBM Rational, we are not using OpenSolaris at all - we are tasked with making things work on Solaris 10, not OpenSolaris. What external version of Solaris 10 will have this linker fix, and in what expected timeframe?[/i] http://mail.opensolaris.org/pipermail/tools-linking/2006-October/000235.html I believe that fix is in Solaris 10 Update 4 (also known as 8/07). I also thought that purify contained a workaround for the issue (discussed in that email thread you reference), but I don't know what came of that. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] gcc with GNU ld ?
Akhilesh Mritunjai wrote: Joerg, I'm aware of the issue... but what I'm actually saying is that wouldn't it be more consistent if gcc uses gld and sun cc uses sun ld ? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org gcc and gld are separate programs that solve separate problems. There's no requirement that they be used together. They are, of course, close cousins. Still, I don't think it's more consistent to always pair them no matter what platform you're on. The combination that is most likely to work well is going to be gcc (or cc) with the native linker, be it on Solaris or elsewhere (and note that gld is the native linker in some places, notably Linux). Naturally there are exceptions, but these nearly always come down to one of: 1) The build configuration is gld-centric and is too hard to wrangle for Solaris. 2) The C code makes use of gcc features that really assume gld. I wouldn't say that either of these are a matter of consistency, just pragmatism. Lot's of free software these days assumes a linux environment, and sometimes other platforms don't get as much attention. In both cases, the best thing would be to fix the package to do the right thing under Solaris and contribute the changes back to the maintainer. Full Disclosure: I work at Sun, on the Sun linker. It's OK with me if you use gld though. Good luck! - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Two problems in the nightly build mail
陶捷 Tao Jie wrote: I don't know, but I've succeeded to build ON b66 with SS12 and it works well now. But it's a debug version. And as I've mentioned in the previous email, I fail to Install the non-debug version. 2007/7/6, Boyd Adamson [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Tao Jie [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] writes: Hi, Ali No, you may safely ignore duplicate SUNW_dynsymsort messages. They are more about tidiness than correctness. See here if you are interested in the details: http://www.opensolaris.org/os/community/on/flag-days/pages/2007052202/ I'm surprised to see those errors, as ON should be completely clean following the putback described in that flag day message. One possibility is that you are using a new copy of usr/src/tools/script/check_rtime.pl against an older copy of the libelf code. err... I don't know why it occurs :( I'm building ON b66 on the Solaris Express B66 with Sun Studio 12. Umm... is building with Studio 12 supported yet? Boyd ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org We're not building ON with Studio 12 yet, we're still on Studio 11. My nightly builds with Studio 11 came out clean with regards to SUNW_dynsymsort messages. So, I think the compiler change is likely the cause of those warnings. We'll mop up those warnings as part of the switch to the new compiler (I'm not sure where we are on that). In the meantime, you should feel free to ignore the SUNW_dynsymsort warnings --- they don't change the way the resulting code works. - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Two problems in the nightly build mail
陶捷 Tao Jie wrote: snip Check ELF runtime attributes ./lib/amd64/libelf.so.1: .SUNW_dynsymsort: duplicate 0x00023e38: elf32_getehdr, _elf32_getehdr ./lib/amd64/libelf.so.1: .SUNW_dynsymsort: duplicate 0x000240c8: _elf32_getphdr, elf32_getphdr ./lib/libelf.so.1: .SUNW_dynsymsort: duplicate 0x52a8: elf32_xlatetof, _elf32_xlatetof ./lib/libelf.so.1: .SUNW_dynsymsort: duplicate 0x00015890: _elf32_getehdr, elf32_getehdr ./lib/libelf.so.1: .SUNW_dynsymsort: duplicate 0x00015b1c: _elf32_getphdr, elf32_getphdr ./lib/libelf.so.1: .SUNW_dynsymsort: duplicate 0x00015fd0: elf32_getshdr, _elf32_getshdr * /*** What's the problem here? Is it serious? ***/* No, you may safely ignore duplicate SUNW_dynsymsort messages. They are more about tidiness than correctness. See here if you are interested in the details: http://www.opensolaris.org/os/community/on/flag-days/pages/2007052202/ I'm surprised to see those errors, as ON should be completely clean following the putback described in that flag day message. One possibility is that you are using a new copy of usr/src/tools/script/check_rtime.pl against an older copy of the libelf code. I have a full nightly build of the latest sources building right now for other reasons, so I'll be able to double check that assertion in a few hours... - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] librtld_db failed to initialize; symbols from
Madhusudhan Reddy wrote: Thanks mph i have checked the values of ulimit for both process and file...both are set as unlimited. As you have said that core might be truncated.Actually i have seen this problem coming only a few times...why is it so ? I have taken the output of truss and but i cannot analyse them... please help if you can Thanks, Madhusudhan Reddy Can you clarify what you mean when you say you've only seeing this a few times? Does it happen every time on this particular program, but not otherwise? Or do you mean that it sometimes fails with this particular program, but other times it succeeds? - Ali ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
