Andy Polyakov wrote:
But without splitting -Wl,-Fl from libssl.a with
a space,
??? 'cc -b -Wl,-Fl,libssl.a ...' should be/is translated to 'ld -b -Fl
libssl.a ...' by cc. Comma in cc -Wl stands for space in ld line.
Yes, that is absolutely correct. However, you are telling cc to pass this
through without thinking about it, correct? So cc doesn't know that, in
fact, there is a source object (libssl.a) because it was burried in a -Wl.
Therefore cc thinks there are no inputs, and does nothing.
Change to a space and now ld gets to chew on it.
Secondly, once we remove the space,
You contradict yourself: first you say "space is required," and here you
say "space has to be removed." Make up your mind:-)
Yes, I mistyped.
Once we have a space, and therefore, one input (a .a file)
we crash out with
/usr/ccs/bin/ld: CODE_ONE_SYM fixup to non-code subspace in file
/opt/langtools/lib/crt0.o - shared library must be position
independent. Use +z or +Z to recompile.
'cc -b ...' should be/is translated to 'ld -b ...' *without* crt0.o. Add
-v flag to the above command line and test with and without -b.
cc in this case did add crt0.o <shrug>. I will retest this theory with
otherwise absolutely minimum changes, verify the results and report back
what ld was given.
http://mail.gnome.org/archives/gtk-list/1999-March/msg00704.html reports
similar issues, with no resolution on how-to-exclude crt0.o from the 'cc'
flavor,
They were using -Wl,-b, while you're expected to pass -b directly to cc.
Ack, I see that, but the two mean different things I expect. -b to hp ld
means no built in link paths (same as +b disable to chatr).
Finally -b +s disappeared between 0.9.7e and 0.9.7i,
??? You yourself have presented evidence that -b is there [command line
above].
That's HPUX -b which means something quite different than cc thinks.
Again, I'll retest and report back.
As for +s, it's used to link executables [where it's actually
effective], but not to lib*.sl [where it does nothing anyway]. Verify
the application link command line for presence of +s.
chatr tells me it's staticbound, and I desired to follow SHLIB_PATH. But
this is fair disagreement on the point. I can override with my own LDFLAGS
choice, but it's a -change- from 0.9.6/.7 prior versions, therefore likely
to bite someone. +s determines that SHLIB_PATH is used to follow -this-
binaries (executable or shared lib) dependent libs are found. I concur,
it might not be necessary, so I'll drop the question for the moment.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
