...specifically, the /AL option? I am porting some ancient C (a Freescale nee Motorala M68000 simulator) and I can't find it on MSDN. Google retrieves many non-related links, and the Wayback Internet Archive chokes beyond the "Product Release" page. Note that this switch seems not to be present in version 6, but resurfaces in .Net as:
"/AL Specifies a directory to search to resolve file references passed to the #using directive"
These files are neither C++ nor C#, su that ain't right...
an example: cl -c -AL CODE1.C
I guess it sets the memory model to Large. That page reminded me of it: http://msdn.microsoft.com/en-us/library/aa225257%28v=sql.80%29.aspx
Oh, those were the days...
Update: Here's the full set: http://gunkies.org/wiki/Microsoft_C_5.1
Related
I have some old codes which I use for my database.
I wrongly deleted the EXE files and now I only have some .BAT files for Clipper. The PRG files of my program which contains the source codes, and other files (DBF, NTX, ...).
How to make the exe files again? I found only a command to compile the PRG.
clipper myfile.prg
Execute:
clipper test.prg test.obj
blinker fi test.obj test.exe
if you have dependencies, check on your .rmk file.
touch project.rmk
rmake project.rmk
hope this helps
When using clipper to compile and plink86 to link, you need to also specify the clipper libraries. For example, if the only .prg file you are working on is zmenu.prg, then you would first:
clipper zmenu.prg
And then to link it:
plink86 fi zmenu lib clipper, extend
That's off the top of my head, but it should be close. If you can get your hands on a clipper manual I know it has more details on how to do this in the apendix of the manual.
I preferred linkfiles myself, but I dont remember the format. Then you just had to do:
plink86 #linkfile
So if you were doing compiling and testing a lot, it was easy to do without having to type the longer command each time.
I hope this helps. Wow, dusting off my clipper cobwebs :)
Very old question, but just to clarify in case anybody else has this issue, any MS compatible linker will work. You don't need a "Clipper" linker.
I am trying to navigate and understand whoami (and other coreutils) all the way down to the lowest level source code, just as an exercise.
My dive so far:
Where is the actual binary?
which whoami
/usr/bin/whoami
Where is it maintained?
http://www.gnu.org/software/coreutils/coreutils.html
How do I get source?
git clone git://git.sv.gnu.org/coreutils
Where is whoami source code within the repository?
# find . | grep whoami
./man/whoami.x
./man/whoami.1
./src/whoami.c
./src/whoami
./src/whoami.o
./src/.deps/src_libsinglebin_whoami_a-whoami.Po
./src/.deps/whoami.Po
relevant line (84):
uid = geteuid ();
This is approximately where my rabbit hole stops. geteuid() is mentioned in gnulib/lib/euidaccess.c, but not explicitly defined AFAICT. It's also referenced in /usr/local/unistd.h as extern but there's no heavy lifting related to grabbing a uid that I can see.
I got here by mostly grepping for geteuid within known system headers and includes as I'm having trouble backtracing its definition.
Question: How can I dive down further and explore the source code of geteuid()? What is the most efficient way to explore this codebase quickly without grepping around?
I'm on Ubuntu server 15.04 using Vim and some ctags (which hasn't been very helpful for navigating existing system headers). I'm a terrible developer and this is my method of learning, though I can't get through this roadblock.
Normally you should read the documentation for geteuid. You can either read GNU documentation, the specification from the Open Group or consult the man page.
If that doesn't help you could install the debug symbols for the c-library (it's called libc6-dbg or something similar) and download the source code for libc6) then you point out the path to the source file when you step into the library.
In this case I don't think this would take you much further, what probably happens in geteuid is that it simply issues an actual syscall and then it's into kernel space. You cannot debug that (kernel) code in the same way as you would debug a normal program.
So in your case you should better consult the documentation and read it carefully and try to figure out why geteuid doesn't return what you expect. Probably this will lead to you changing your expectation of what geteuid should return to match what's actually returned.
I followed a guide on the internet and everything works as described.
The step 10 in the guide confuses me though.
I previousely created an archive file of gtest and called it libgtest.a.
The guide explicitely tells me to enter gtest and not libgtest.a
I wonder why this would be true since at no other point i mention libgtest.a anywhere.
How does the MinGW C++ Linker know what file to use?
The directory contains other files that have gtest in their name.
It is a common GCC convention - when you pass -lname linker automatically search for libname.a. See https://gcc.gnu.org/onlinedocs/gcc/Link-Options.html and -l option
Im stuck on compiling the tsr.asm code provided in the book rootkit arsenal.
I installed open watcom on a XP maschine and the first asm listing was compiled well.
When compiling, it throws the error: "multiple starting address found" (nothing found on google). Can anyone confirm that this code is compilable, and how?
Im thankful for any suggestions.
When you're writing some code, there is a particular address where the execution is to begin (the main function in C for example), but in your code there are more than one starting address, and it crashes when compiling. But without seeing the code I can't tell you more.
Sorry for the late answer, but I was searching for an answer to this and just figured it out - hopefully it'll help someone else Googling around for an answer.
Since you're using OpenWatcom (I'm using version 1.9), I'll assume that you have tsr.asm in its own OpenWatcom 16-bit DOS COM project. In the IDE, go to Targets -> Target Options -> Linker Switches. In the window that appears, select "2. Import, Export and Library Switches" from the drop-down at the top and remove the cstart_t entry under "Library files(,): [libf]".
Recompile, and your TSR COM file should be generated.
I'm integrating .NET support into our C++ application.
It's an old-school MFC application, with 1 extra file compiled with the "/clr" option that references a CWinFormsControl.
I'm not allowed to remove the linker flag "/NODEFAULTLIB".
(We have our own build management system, not Visual Studio's.)
This means I have to specify all necessary libraries: VC runtime and MFC.
Other compiler options include "/MD"
Next to that: I can't use the linker flag "/FORCE:MULTIPLE" and just add everything:
I'm looking for a non-overlapping set of libraries.
As a bare minimum:
mscoree.lib
MSVCRT.lib
mfc90.lib (adjust version appropriately)
And iterate from there.
Use the AppWizard to create a bare-bones MFC app in your style (SDI / MDI / dialog ) and then put on your depends.
How I solved it:
link with "/FORCE:MULTIPLE /verbose" (that links ok) and set the output aside.
link with "/NODEFAULTIB /verbose" and trace all unresolveds in the output of the previous step and add the libraries 1 by 1.
This resulted in doubles: "AAA.lib: XXX already defined in BBB.lib"
Then I finally got it:
Recompiled managed AND unmanaged units with /MD
and link to (among others):
mscoree.lib
msvcmrt.lib
mfcm80d.lib
Mixing /MT (unmanaged) and /MD (managed) turned out to be the bad idea:
different(overlapping) libraries are needed.
#ajryan: Dependcy Walker only tells me what dll's are used, not what libraries are linked to when linking.
(e.g. msvcmrt.lib ?)
I think.
Thanks for the answers!
Jan